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.

unRAID Server Release 5.0-rc16c Available

Featured Replies

It appears as if Tom is using a belt-and-suspenders approach.  First try using an IOCTL call (the belt), then, if that does not work, see if smartctl can return something (the suspenders).

 

So there is no belt then per:

Changes from 5.0-beta4 to 5.0-beta5

-----------------------------------

- webGui: use smartctl program to enable SMART and get disk temperatures instead of ioctl()'s.

 

Looks like Tom could educate us here on how unRAID goes about doing this procedure exactly.

  • Replies 392
  • Views 140.9k
  • Created
  • Last Reply

OK, so I spun down all drives, spun up only Disk#17, started a large file copy, grabbed a sticky pad to label which hotswap drive tray the disk is in, ran down to the server rack, I see the parity and Disk#17 clearly with activity lights. Pushed on a sticky note on the hotswap tray of Disk#17. Went back up, wait for the copy to complete. Browse over to the WebGui to proceed to stop the array (then I was going to remove and re-insert the drive as the first test), but first click refresh in the WebGui. Wait, Disk #17 showing temp...

 

So pushing the drive tray by applying the sticky note to label it reseated it. Ran a smart command, all came back with no issue against the drive. So this is one for the history books.

 

Look what we got out of this, knowing what a not fully seated drive looks like in syslog, and two new upgraded components which makes unRAID fly.

 

Thanks to all (you crazy smart people) for sticking with this. Wife wants to watch a movie NOW! Gotta run. Rest of the testing will commence tomorrow.

 

Like madburg suggested, I did reboot in safe mode to eliminate possible plugin influences on my problem. I put the system into sleep mode by issuing:

echo -n mem > /usr/power/state

 

The problematic part of the syslog stays the same:

Jul  8 13:55:08 lafiel kernel: mpt2sas1: pdev=0xeb2f0000, slot=0000:02:00.0, entering operating state [D3]
Jul  8 13:55:08 lafiel kernel: mpt2sas1: sending message unit reset !!
Jul  8 13:55:08 lafiel kernel: mpt2sas0: pdev=0xeb06f800, slot=0000:01:00.0, entering operating state [D3]
Jul  8 13:55:08 lafiel kernel: mpt2sas0: sending message unit reset !!
Jul  8 13:55:08 lafiel kernel: mpt2sas1: message unit reset: SUCCESS
Jul  8 13:55:08 lafiel kernel: mpt2sas0: message unit reset: SUCCESS
Jul  8 13:55:08 lafiel kernel: ------------[ cut here ]------------
Jul  8 13:55:08 lafiel kernel: WARNING: at drivers/pci/pci.c:1393 pci_disable_device+0x50/0x79()
Jul  8 13:55:08 lafiel kernel: Hardware name: To Be Filled By O.E.M.
Jul  8 13:55:08 lafiel kernel: Device mpt2sas
Jul  8 13:55:08 lafiel kernel: disabling already-disabled device
Jul  8 13:55:08 lafiel kernel: Modules linked in: w83627ehf hwmon_vid md_mod sg i2c_i801 i2c_core mpt2sas scsi_transport_sas raid_class coretemp hwmon ahci libahci r8168(O)
Jul  8 13:55:08 lafiel kernel: Pid: 3118, comm: kworker/u:10 Tainted: G           O 3.9.6p-unRAID #23
Jul  8 13:55:08 lafiel kernel: ------------[ cut here ]------------
Jul  8 13:55:08 lafiel kernel: Call Trace:
Jul  8 13:55:08 lafiel kernel: WARNING: at drivers/pci/pci.c:1393 pci_disable_device+0x50/0x79()
Jul  8 13:55:08 lafiel kernel: Hardware name: To Be Filled By O.E.M.
Jul  8 13:55:08 lafiel kernel:  [<c1029269>] warn_slowpath_common+0x77/0x8e
Jul  8 13:55:08 lafiel kernel: Device mpt2sas
Jul  8 13:55:08 lafiel kernel: disabling already-disabled device
Jul  8 13:55:08 lafiel kernel:  [<c1276a75>] ? pci_disable_device+0x50/0x79
Jul  8 13:55:08 lafiel kernel: Modules linked in: w83627ehf
Jul  8 13:55:08 lafiel kernel:  [<c1276a75>] ? pci_disable_device+0x50/0x79
Jul  8 13:55:08 lafiel kernel:  hwmon_vid md_mod
Jul  8 13:55:08 lafiel kernel:  [<c10292fc>] warn_slowpath_fmt+0x2e/0x30
Jul  8 13:55:08 lafiel kernel:  sg i2c_i801
Jul  8 13:55:08 lafiel kernel:  [<c1276a75>] pci_disable_device+0x50/0x79
Jul  8 13:55:08 lafiel kernel:  i2c_core mpt2sas scsi_transport_sas
Jul  8 13:55:08 lafiel kernel:  [<f8552107>] _scsih_suspend+0x79/0x8c [mpt2sas]
Jul  8 13:55:08 lafiel kernel:  raid_class coretemp
Jul  8 13:55:08 lafiel kernel:  [<c12779f1>] pci_legacy_suspend+0x24/0x9e
Jul  8 13:55:08 lafiel kernel:  hwmon ahci
Jul  8 13:55:08 lafiel kernel:  [<c1277e78>] pci_pm_suspend+0x31/0xe1
Jul  8 13:55:08 lafiel kernel:  libahci r8168(O)
Jul  8 13:55:08 lafiel kernel: 
Jul  8 13:55:08 lafiel kernel:  [<c12e0eb9>] ? device_pm_wait_for_dev+0x1b/0x1b
Jul  8 13:55:08 lafiel kernel: Pid: 3124, comm: kworker/u:16 Tainted: G           O 3.9.6p-unRAID #23
Jul  8 13:55:08 lafiel kernel: Call Trace:
Jul  8 13:55:08 lafiel kernel:  [<c13f591f>] ? klist_next+0x29/0xa3
Jul  8 13:55:08 lafiel kernel:  [<c1029269>] warn_slowpath_common+0x77/0x8e
Jul  8 13:55:08 lafiel kernel:  [<c1401fab>] ? wait_for_completion+0x12/0x14
Jul  8 13:55:08 lafiel kernel:  [<c1276a75>] ? pci_disable_device+0x50/0x79
Jul  8 13:55:08 lafiel kernel:  [<c1277e47>] ? pci_pm_resume+0xa0/0xa0
Jul  8 13:55:08 lafiel kernel:  [<c1276a75>] ? pci_disable_device+0x50/0x79
Jul  8 13:55:08 lafiel kernel:  [<c12e0f37>] dpm_run_callback+0x14/0x3f
Jul  8 13:55:08 lafiel kernel:  [<c10292fc>] warn_slowpath_fmt+0x2e/0x30
Jul  8 13:55:08 lafiel kernel:  [<c12e4299>] ? pm_runtime_barrier+0x48/0x6f
Jul  8 13:55:08 lafiel kernel:  [<c1276a75>] pci_disable_device+0x50/0x79
Jul  8 13:55:08 lafiel kernel:  [<c12e161c>] __device_suspend+0x19e/0x1e4
Jul  8 13:55:08 lafiel kernel:  [<f8552107>] _scsih_suspend+0x79/0x8c [mpt2sas]
Jul  8 13:55:08 lafiel kernel:  [<c12e167c>] async_suspend+0x1a/0x75
Jul  8 13:55:08 lafiel kernel:  [<c12779f1>] pci_legacy_suspend+0x24/0x9e
Jul  8 13:55:08 lafiel kernel:  [<c10431c8>] async_run_entry_fn+0x69/0x128
Jul  8 13:55:08 lafiel kernel:  [<c1277e78>] pci_pm_suspend+0x31/0xe1
Jul  8 13:55:08 lafiel kernel:  [<c1039b5f>] process_one_work+0x1cb/0x2cc
Jul  8 13:55:08 lafiel kernel:  [<c12e0eb9>] ? device_pm_wait_for_dev+0x1b/0x1b
Jul  8 13:55:08 lafiel kernel:  [<c103a0f4>] worker_thread+0x1c3/0x2f8
Jul  8 13:55:08 lafiel kernel:  [<c13f591f>] ? klist_next+0x29/0xa3
Jul  8 13:55:08 lafiel kernel:  [<c103eb75>] kthread+0x90/0x95
Jul  8 13:55:08 lafiel kernel:  [<c1401fab>] ? wait_for_completion+0x12/0x14
Jul  8 13:55:08 lafiel kernel:  [<c1039f31>] ? manage_workers+0x89/0x89
Jul  8 13:55:08 lafiel kernel:  [<c1277e47>] ? pci_pm_resume+0xa0/0xa0
Jul  8 13:55:08 lafiel kernel:  [<c1403837>] ret_from_kernel_thread+0x1b/0x28
Jul  8 13:55:08 lafiel kernel:  [<c12e0f37>] dpm_run_callback+0x14/0x3f
Jul  8 13:55:08 lafiel kernel:  [<c103eae5>] ? kthread_freezable_should_stop+0x4a/0x4a
Jul  8 13:55:08 lafiel kernel:  [<c12e4299>] ? pm_runtime_barrier+0x48/0x6f
Jul  8 13:55:08 lafiel kernel: ---[ end trace 7a9bb4fc1501b3ef ]---
Jul  8 13:55:08 lafiel kernel:  [<c12e161c>] __device_suspend+0x19e/0x1e4
Jul  8 13:55:08 lafiel kernel:  [<c12e167c>] async_suspend+0x1a/0x75
Jul  8 13:55:08 lafiel kernel:  [<c10431c8>] async_run_entry_fn+0x69/0x128
Jul  8 13:55:08 lafiel kernel:  [<c1039b5f>] process_one_work+0x1cb/0x2cc
Jul  8 13:55:08 lafiel kernel:  [<c103a0f4>] worker_thread+0x1c3/0x2f8
Jul  8 13:55:08 lafiel kernel:  [<c103eb75>] kthread+0x90/0x95
Jul  8 13:55:08 lafiel kernel:  [<c1039f31>] ? manage_workers+0x89/0x89
Jul  8 13:55:08 lafiel kernel:  [<c1403837>] ret_from_kernel_thread+0x1b/0x28
Jul  8 13:55:08 lafiel kernel:  [<c103eae5>] ? kthread_freezable_should_stop+0x4a/0x4a
Jul  8 13:55:08 lafiel kernel: ---[ end trace 7a9bb4fc1501b3f0 ]---
Jul  8 13:55:08 lafiel kernel: sd 8:0:0:0: [sdd] Stopping disk
Jul  8 13:55:08 lafiel kernel: PM: suspend of devices complete after 1080.031 msecs
Jul  8 13:55:08 lafiel kernel: PM: late suspend of devices complete after 0.113 msecs
Jul  8 13:55:08 lafiel kernel: ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
Jul  8 13:55:08 lafiel kernel: ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
Jul  8 13:55:08 lafiel kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
Jul  8 13:55:08 lafiel kernel: PM: noirq suspend of devices complete after 59.732 msecs
Jul  8 13:55:08 lafiel kernel: ACPI: Preparing to enter system sleep state S3
Jul  8 13:55:08 lafiel kernel: PM: Saving platform NVS memory
Jul  8 13:55:08 lafiel kernel: Disabling non-boot CPUs ...
Jul  8 13:55:08 lafiel kernel: smpboot: CPU 1 is now offline

 

@limetech:

Could you please have a look at this? Thank you very much. :)

syslog-2013-07-08.zip

Uh, why?

Looking at the name of it, smartmontools you posted is 64-bit. What good does that do us?

And how's the version of hdparm any different from the one I posted?

 

Fixed packages, it was 32bit, just wrong name....

 

Because someone are testing with newer version, and it looks like they do some progress.....

 

Uh, why?

And how's the version of hdparm any different from the one I posted?

http://lime-technology.com/forum/index.php?topic=28382.msg252706#msg252706

 

Missed that post, then I have done all my work unnecessarily.

//Peter

 

 

Installed these 2, and it looks like Smart History from unMenu looks running much faster.....

Uh, why?

Looking at the name of it, smartmontools you posted is 64-bit. What good does that do us?

And how's the version of hdparm any different from the one I posted?

 

Fixed packages, it was 32bit, just wrong name....

 

Because someone are testing with newer version, and it looks like they do some progress.....

 

//Peter

I made the switch to rc16c today. Looking at my syslog, there are two things that didn't happen with rc12a.

 

Firstly there seem to be memory problems? At least unmenu highlights them in red:

Jul  7 19:18:01 lafiel kernel: init_memory_mapping: [mem 0x00000000-0x000fffff]
Jul  7 19:18:01 lafiel kernel:  [mem 0x00000000-0x000fffff] page 4k
Jul  7 19:18:01 lafiel kernel: init_memory_mapping: [mem 0x37800000-0x379fffff]
Jul  7 19:18:01 lafiel kernel:  [mem 0x37800000-0x379fffff] page 2M
Jul  7 19:18:01 lafiel kernel: init_memory_mapping: [mem 0x34000000-0x377fffff]
Jul  7 19:18:01 lafiel kernel:  [mem 0x34000000-0x377fffff] page 2M
Jul  7 19:18:01 lafiel kernel: init_memory_mapping: [mem 0x00100000-0x1fffffff]
Jul  7 19:18:01 lafiel kernel:  [mem 0x00100000-0x001fffff] page 4k
Jul  7 19:18:01 lafiel kernel:  [mem 0x00200000-0x1fffffff] page 2M
Jul  7 19:18:01 lafiel kernel: init_memory_mapping: [mem 0x20200000-0x33ffffff]
Jul  7 19:18:01 lafiel kernel:  [mem 0x20200000-0x33ffffff] page 2M
Jul  7 19:18:01 lafiel kernel: init_memory_mapping: [mem 0x37a00000-0x37bfdfff]
Jul  7 19:18:01 lafiel kernel:  [mem 0x37a00000-0x37bfdfff] page 4k

 

and then there are problems when I make the system sleep:

Jul  7 19:51:52 lafiel kernel: ------------[ cut here ]------------
Jul  7 19:51:52 lafiel kernel: WARNING: at drivers/pci/pci.c:1393 pci_disable_device+0x50/0x79() (Minor Issues)
Jul  7 19:51:52 lafiel kernel: Hardware name: To Be Filled By O.E.M.
Jul  7 19:51:52 lafiel kernel: Device mpt2sas (Drive related)
Jul  7 19:51:52 lafiel kernel: disabling already-disabled device
Jul  7 19:51:52 lafiel kernel: Modules linked in: w83627ehf hwmon_vid md_mod sg mpt2sas i2c_i801 i2c_core scsi_transport_sas raid_class ahci libahci r8168(O) coretemp hwmon (Drive related)
Jul  7 19:51:52 lafiel kernel: Pid: 2075, comm: kworker/u:2 Tainted: G           O 3.9.6p-unRAID #23 (Errors)
Jul  7 19:51:52 lafiel kernel: Call Trace: (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c1029269>] warn_slowpath_common+0x77/0x8e (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c1276a75>] ? pci_disable_device+0x50/0x79 (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c1276a75>] ? pci_disable_device+0x50/0x79 (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c10292fc>] warn_slowpath_fmt+0x2e/0x30 (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c1276a75>] pci_disable_device+0x50/0x79 (Errors)
Jul  7 19:51:52 lafiel kernel:  [<f8570107>] _scsih_suspend+0x79/0x8c [mpt2sas] (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c12779f1>] pci_legacy_suspend+0x24/0x9e (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c1277e78>] pci_pm_suspend+0x31/0xe1 (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c12e0eb9>] ? device_pm_wait_for_dev+0x1b/0x1b (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c13f591f>] ? klist_next+0x29/0xa3 (Errors)
Jul  7 19:51:52 lafiel kernel:  [<c1401fab>] ? wait_for_completion+0x12/0x14 (Errors)

 

Anybody with more knowledge can tell me what goes wrong? It might be something not stock unraid related, so moderators feel free to move it to a seperate thread.

 

Does the system sleep? Why do you think these are problems? Issues with sleep should be discussed in the User Customizations forum.

due to lack of temperatures and spindown support for RDM'd drives. I'll give this a go tomorrow... will be great if this works!

You will need to be near your machine to see if they spin down or spin up.

I cannot tell at the current moment, the AC is on, I'm blasting Santana and programming.

 

While the drives did not show spin up or spin down before in my HP micro server.

I could tell they were spinning down due to time to access and hearing them spin up.

Too much going on for me to verify this right now.

 

Just in case this helps anyone else, I've just tested this without updating the version of hdparm and smartmontools... and I'm able to see drive temperatures and spin up/down RDM'd drives!! I'll have to test it out a little more to make sure everything still works as expected, but I'm hopeful now that I may be able to make the leap to ESXi without needing new hardware!  ;D

 

Maybe this is as a result of one of the newer kernel versions since I last tested under RC8A?

 

Anyway, thanks for posting your observations Weebo, or I wouldn't have given this another go!  ;)

 

EDIT: Okay, it's not as clear cut as I first thought, the drives connected to my SAS card seem to work perfectly, the drives connected to onboard controller don't seem to.

Does the system sleep? Why do you think these are problems? Issues with sleep should be discussed in the User Customizations forum.

Its been covered already, Tom supports Sleep. He has bases to post here.

You may have missed his latest post (few up), he is using safe mode to ensure no plugins are loading, it worked with his MB previously and it does not in this release. He's posting syslog's (in both posts) for help and Tom's review.

 

He was already been made aware by JoeL. that the lines about memory are not an issue.

Why do I need all that avahi stuff??  I've got nothing to do with any macs on my network!  Wasn't there a preference if you want to enable mac-stuff?  My mac-stuff option is set on disabled.

 

It stems from this post: http://lime-technology.com/forum/index.php?topic=27820.0

 

Quote from Tom

 

I changed AVAHI handling for 5.0 'final' as follows.  First, AVAHI is now always enabled.  This lets you get to the webGui in a pure-OSX environment by typing "tower.local" in your browser address bar, instead of having to either edit a config file to enable afp or finding your ip address and entering that. [This is why I made this change.]

 

The effect of this is that:

(substitute your server name for "tower" below if you changed it)

 

a) if SMB is enabled and AFP is disabled (which is the default), Finder shows "tower-smb" and lets you access files using the SMB protocol.

 

b) if SMB is enabled and AFP is enabled, you get two entries in Finder: "tower" and "tower-smb".  Access is via AFP for "tower" and via SMB via "tower-smb".

 

c) if SMB is disabled and AFP is enabled, you only get one entry in Finder, "tower", and access is via AFP.

 

d) if both SMB and AFP disabled, nothing in Finder, but you still can access the webGui via "tower.local".

 

So, no way to turn off AVAHI completely.  If this proves to be problem, I'll add that control post-5.0-final.

 

I originally thought it was going to be a controllable feature in the 'AFP' sub component, sort of like the additions that were added and are controllable for 'NFS'

 

I just noticed in "rc-16c" that some avahi stuff is being started on my server...

Jul  7 20:30:17 VBox-v5-RC avahi-daemon[1741]: Invalid legacy unicast query packet.
Jul  7 20:30:17 VBox-v5-RC avahi-daemon[1741]: Invalid legacy unicast query packet.
Jul  7 20:30:18 VBox-v5-RC avahi-daemon[1741]: Invalid legacy unicast query packet.
Jul  7 20:30:18 VBox-v5-RC avahi-daemon[1741]: Received response from host 192.168.56.1 with invalid source port 1242 on interface 'eth1.0'
Jul  7 20:30:18 VBox-v5-RC avahi-daemon[1741]: Invalid legacy unicast query packet.
Jul  7 20:30:18 VBox-v5-RC avahi-daemon[1741]: Invalid legacy unicast query packet.
Jul  7 20:30:19 VBox-v5-RC avahi-daemon[1741]: Invalid legacy unicast query packet.
Jul  7 20:30:19 VBox-v5-RC avahi-daemon[1741]: Received response from host 192.168.56.1 with invalid source port 1242 on interface 'eth1.0'
Jul  7 20:30:19 VBox-v5-RC avahi-daemon[1741]: Received response from host 192.168.56.1 with invalid source port 1242 on interface 'eth1.0'
Jul  7 20:30:20 VBox-v5-RC avahi-daemon[1741]: Received response from host 192.168.56.1 with invalid source port 1242 on interface 'eth1.0'

Why do I need all that avahi stuff??  I've got nothing to do with any macs on my network!  Wasn't there a preference if you want to enable mac-stuff?  My mac-stuff option is set on disabled.

 

 

Could it be the same thing as here http://lime-technology.com/forum/index.php?topic=28353.msg252045#msg252045

 

VirtualBox related it looks like

@dgaschk and madburg

The system does sleep! So it's not a "critical" problem. But those messages are new (in comparision to rc12a) and highlighted in red in unmenus syslog utility, which makes me a bit nervous. (@Joe L.: This time unmenu is updated. :) ) I posted them for the experts to tell me if they are errors or if I should just ignore them.

 

The messages show, that the system tries to disable the already disabled devices a second time, which might indicate a problem. I just don't know and wanted to report it just in case.

 

edit:

I read again Joe L.'s first post regarding my problem. He there says those lines might be informational, too. I must have missed it the first time.  :-[  So it seems he'll have to fix those showing in red in unmenu and its not an possible unraid error.

@dgaschk and madburg

The system does sleep! So it's not a "critical" problem. But those messages are new (in comparision to rc12a) and highlighted in red in unmenus syslog utility, which makes me a bit nervous. (@Joe L.: This time unmenu is updated. :) ) I posted them for the experts to tell me if they are errors or if I should just ignore them.

 

The messages show, that the system tries to disable the already disabled devices a second time, which might indicate a problem. I just don't know and wanted to report it just in case.

 

edit:

I read again Joe L.'s first post regarding my problem. He there says those lines might be informational, too. I must have missed it the first time.  :-[  So it seems he'll have to fix those showing in red in unmenu and its not an possible unraid error.

 

I basically concur with Joe L, although I would prefer to say that it should be *treated* as informational, even though the messages and behavior are clearly not right.  The only misbehavior apparent though is that the mpt2sas driver module does not appear to be programmed to expect a second instance to be disabled.  The fix would be a newer version of mpt2sas.

 

I have to say that none of the SAS support modules appear to be very mature to me, and I hope Tom will continue to look for newer versions to include, after v5.0 Final of course.  [drifting off-topic here] In fact, if I were preparing an LTS version of UnRAID, I would have to strip out all of the SAS support, and probably the Realtek support, and perhaps other things, but then who would want it?  By its nature, and the constant demand for support of the latest storage technologies, UnRAID is forced to be cutting edge, staying just behind the latest releases.  That is not exactly compatible with its original mission as a rock-solid totally stable file server.

Now that u mention it RobJ, I noticed that the mpt2sas driver is v14 in these kernel's and requested privately to Tom to look out for v16 if available and can be added.

I upgraded to RC16c not too long ago, and let it run. Its been running fine for a handful of days, but today when I tried to copy the new Firefall Beta installer to my array, transfer speeds were abysmally slow (maxing out at 10mbps, attached screenshot shows 4mbps). Read speeds are fine, right around 40. I had put in some custom settings for md_num_stripes, md_write_limit, and md_sync_window (just randomly picked some numbers but made sure that num_stripes was equal to write_limit + sync_window), but I reset those to default, renamed all my plugin folders, and rebooted. I'm running stock unraid rc16c (except for unmenu and I forgot to rename my "extra" folder so I have Plex). Any ideas? Syslog attached.

write_speed.PNG.a7a7ea3e6b79e73812fb155f9b00da73.PNG

syslog.txt

I upgraded to RC16c not too long ago, and let it run. Its been running fine for a handful of days, but today when I tried to copy the new Firefall Beta installer to my array, transfer speeds were abysmally slow (maxing out at 10mbps, attached screenshot shows 4mbps). Read speeds are fine, right around 40. I had put in some custom settings for md_num_stripes, md_write_limit, and md_sync_window (just randomly picked some numbers but made sure that num_stripes was equal to write_limit + sync_window), but I reset those to default, renamed all my plugin folders, and rebooted. I'm running stock unraid rc16c (except for unmenu and I forgot to rename my "extra" folder so I have Plex). Any ideas? Syslog attached.

 

If you read the release notes there is now a safe boot mode you can select on boot or by having a file on you flash drive so u don't need to rename everyting

@dgaschk and madburg

The system does sleep! So it's not a "critical" problem. But those messages are new (in comparision to rc12a) and highlighted in red in unmenus syslog utility, which makes me a bit nervous. (@Joe L.: This time unmenu is updated. :) ) I posted them for the experts to tell me if they are errors or if I should just ignore them.

 

The messages show, that the system tries to disable the already disabled devices a second time, which might indicate a problem. I just don't know and wanted to report it just in case.

 

edit:

I read again Joe L.'s first post regarding my problem. He there says those lines might be informational, too. I must have missed it the first time.  :-[  So it seems he'll have to fix those showing in red in unmenu and its not an possible unraid error.

 

I basically concur with Joe L, although I would prefer to say that it should be *treated* as informational, even though the messages and behavior are clearly not right.  The only misbehavior apparent though is that the mpt2sas driver module does not appear to be programmed to expect a second instance to be disabled.  The fix would be a newer version of mpt2sas.

 

I have to say that none of the SAS support modules appear to be very mature to me, and I hope Tom will continue to look for newer versions to include, after v5.0 Final of course.  [drifting off-topic here] In fact, if I were preparing an LTS version of UnRAID, I would have to strip out all of the SAS support, and probably the Realtek support, and perhaps other things, but then who would want it?  By its nature, and the constant demand for support of the latest storage technologies, UnRAID is forced to be cutting edge, staying just behind the latest releases.  That is not exactly compatible with its original mission as a rock-solid totally stable file server.

Sorry if this is a dumb question, but is there a reason that the drivers for these problem cards can't be compiled and loaded separately from the main Unraid package. Seems like it would be desirable to decouple extended hardware support from the core software to simplify support.

 

 

Sent from my iPhone using Tapatalk

I tried to copy  ...  transfer speeds were abysmally slow ...  Any ideas?

Yeah. You've got crapload of memory there. Try booting with less than 4095MB of RAM, and then let's see if you'll have a problem.

 

Dropped to 4096 MB RAM, speeds went way up. Thanks for the advice.

 

I upgraded to RC16c not too long ago, and let it run. Its been running fine for a handful of days, but today when I tried to copy the new Firefall Beta installer to my array, transfer speeds were abysmally slow (maxing out at 10mbps, attached screenshot shows 4mbps). Read speeds are fine, right around 40. I had put in some custom settings for md_num_stripes, md_write_limit, and md_sync_window (just randomly picked some numbers but made sure that num_stripes was equal to write_limit + sync_window), but I reset those to default, renamed all my plugin folders, and rebooted. I'm running stock unraid rc16c (except for unmenu and I forgot to rename my "extra" folder so I have Plex). Any ideas? Syslog attached.

 

If you read the release notes there is now a safe boot mode you can select on boot or by having a file on you flash drive so u don't need to rename everyting

 

I knew there was a safe boot mode, but I was at work and my server runs headless anyway, so I couldn't specify that option at boot. I'll have a look at the release notes  to find the file you mentioned. Thanks!

  • Author

Dropped to 4096 MB RAM, speeds went way up. Thanks for the advice.

Please repeat experiment on completely stock install.

I upgraded to RC16c not too long ago, and let it run. Its been running fine for a handful of days, but today when I tried to copy the new Firefall Beta installer to my array, transfer speeds were abysmally slow (maxing out at 10mbps, attached screenshot shows 4mbps). Read speeds are fine, right around 40. I had put in some custom settings for md_num_stripes, md_write_limit, and md_sync_window (just randomly picked some numbers but made sure that num_stripes was equal to write_limit + sync_window), but I reset those to default, renamed all my plugin folders, and rebooted. I'm running stock unraid rc16c (except for unmenu and I forgot to rename my "extra" folder so I have Plex). Any ideas? Syslog attached.

 

How were file transfers when you first booted RC16c were they good and then went slow after 3 days??  If so just booting up with that mem option may not mean anything as it would be the same as just rebooting you system.  Also did you just use the stock menu mem boot option or did you modify it??

Been running RC15a with no problems.  I decided to give RC16c a try and ran into a couple of issues.  I have the Crashplan Plugin installed.  Crashplan Engine will not start with RC16c (even manually).  Cache disk will also not unmount when trying to shut down the server.  I have Crashplan installed in an .apps folder on the cache drive.  My attempts to start Crashplan may have resulted in some process running that prevents the cache drive from unmounting.

 

I reverted back to RC15a and had neither problem.  Crashplan starts on boot and I can stop the array and unmount all drives without issue.

 

I am running SimpleFeatures and I did note the display issues on the main page that others have noted with RC16c.  I can't really try safemode as problem appears to be plugin related; however, I found it curious that it all works with RC15a and not with RC16c.  Perhaps something has changed in RC16c that affects plugins (the reason for posting in this forum)?

Been running RC15a with no problems.  I decided to give RC16c a try and ran into a couple of issues.  I have the Crashplan Plugin installed.  Crashplan Engine will not start with RC16c (even manually).  Cache disk will also not unmount when trying to shut down the server.  I have Crashplan installed in an .apps folder on the cache drive.  My attempts to start Crashplan may have resulted in some process running that prevents the cache drive from unmounting.

 

I reverted back to RC15a and had neither problem.  Crashplan starts on boot and I can stop the array and unmount all drives without issue.

 

I am running SimpleFeatures and I did note the display issues on the main page that others have noted with RC16c.  I can't really try safemode as problem appears to be plugin related; however, I found it curious that it all works with RC15a and not with RC16c.  Perhaps something has changed in RC16c that affects plugins (the reason for posting in this forum)?

1) A quick boot into safemode and array start and stop never hurts to verify.

after

2) Normal boot, try stopped your plugins manually see which one or more don't and at least then you can bring it up to the plugin author on their thread and see what help they can provide.

Been running RC15a with no problems.  I decided to give RC16c a try and ran into a couple of issues.  I have the Crashplan Plugin installed.  Crashplan Engine will not start with RC16c (even manually).  Cache disk will also not unmount when trying to shut down the server.  I have Crashplan installed in an .apps folder on the cache drive.  My attempts to start Crashplan may have resulted in some process running that prevents the cache drive from unmounting.

 

I reverted back to RC15a and had neither problem.  Crashplan starts on boot and I can stop the array and unmount all drives without issue.

 

I am running SimpleFeatures and I did note the display issues on the main page that others have noted with RC16c.  I can't really try safemode as problem appears to be plugin related; however, I found it curious that it all works with RC15a and not with RC16c.  Perhaps something has changed in RC16c that affects plugins (the reason for posting in this forum)?

Please report these to their respective plugin authors in the customizations or plugins sub-forum.  The plugin will have to adapt to unRAID 5.0.

 

Joe L.

Please report these to their respective plugin authors in the customizations or plugins sub-forum.  The plugin will have to adapt to unRAID 5.0.

 

Joe L.

 

Will do - feel free to delete

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.