unRAID Server Release 6.0-beta6-x86_64 Available

 

 

My motherboard (ASRock E3C224-4L) has 8 SATA ports onboard - but only 6 are being recognized.

 

The two that are not being recognized are on a "Marvell SE9172" controller.

 

On boot and in the BIOS I see the attached drive on these ports, but in unRAID they are not showing up.

 

Is support for this controller included? If not, can it be added.

 

Thanks!

 

That's crazy.  For me 6b6 fixed io issues I was having but maybe it was the newer xen. I have a 2 port 9172 with a ssd for domains and a 2.5" laptop hd for mythtv recording. Also have a 4 port 9230. I just rebuilt a 2GB to 4GB on this controller.  No problems on either. 

 

In the past I put the slower drives on the 9230. I also turned off sata aggressive link power management.  I had a problem with drives dropping off.

 

I have an SAS2LP and a SASLP in the box as well - both other Marvell controllers. Maybe I had some kind of conflict between them.

 

I'll try 6b6 on my system this evening and report if there's any affect on Marvell controllers.

So I've confirmed this Marvell SATA controller issue on unRAID 6Beta6

I tested on a Gigabyte 990FXA-UD5 motherboard which has 2 x Marvell 88SE9172 chips  (driving 2x SATA ports and 2x eSATA ports). I also have a Syba SATA III 4 Port PCI-e 2.0x 2 Card, based on the Marvell 88SE9230 Chipset.

I have drives connected to all of these controllers (in addition to the 6x southbridge SATA ports and a SiL based PCIe 2x port SATA card)

Booting unRAID 6b5a, all drives are accessible

Booting unRAID 6b6, only drives not attached to Marvell controllers are accessible.

During boot, the screen fills with errors similar to the following, with many entries displayed for each of the controller device ids;

AMD-Vi: Event logged [iO_PAGE_FAULT device=01:00.0 domain=0x0017 address=0x0000000000001000 flags=0x0000]

This can be solved by switching off IOMMU in bios, but that of course impacts virtualisation & device passthrough.

There is a fix for this issue in the form of a kernel patch. Full issue discussion and details on bugzilla here;

https://bugzilla.kernel.org/show_bug.cgi?id=42679

Here's the direct link to the patch;

https://lkml.org/lkml/2014/5/22/685

This is not an unRAID issue but rather a Kernel 3.15 (and possibly earlier) issue. I've encountered in on OpenSuSe as well on the same machine. (it's actually a hardware issue with the Marvell controller which misbehaves by addressing memory reserved for IOMMU)

Ideally, the above patch should be applied to the kernel or users with several versions of Marvell SATA controllers will be out of luck (and like me find their controllers broken if upgrading to 6b6)

I'm happy to test pre-release versions if it helps LimeTech.

Peter

Ah ok my system only supports vt-x not vt-d.

 

 

My motherboard (ASRock E3C224-4L) has 8 SATA ports onboard - but only 6 are being recognized.

 

The two that are not being recognized are on a "Marvell SE9172" controller.

 

On boot and in the BIOS I see the attached drive on these ports, but in unRAID they are not showing up.

 

Is support for this controller included? If not, can it be added.

 

Thanks!

 

That's crazy.  For me 6b6 fixed io issues I was having but maybe it was the newer xen. I have a 2 port 9172 with a ssd for domains and a 2.5" laptop hd for mythtv recording. Also have a 4 port 9230. I just rebuilt a 2GB to 4GB on this controller.  No problems on either. 

 

In the past I put the slower drives on the 9230. I also turned off sata aggressive link power management.  I had a problem with drives dropping off.

 

I have an SAS2LP and a SASLP in the box as well - both other Marvell controllers. Maybe I had some kind of conflict between them.

 

I'll try 6b6 on my system this evening and report if there's any affect on Marvell controllers.

 

So I've confirmed this Marvell SATA controller issue on unRAID 6Beta6

 

I tested on a Gigabyte 990FXA-UD5 motherboard which has 2 x Marvell 88SE9172 chips  (driving 2x SATA ports and 2x eSATA ports). I also have a Syba SATA III 4 Port PCI-e 2.0x 2 Card, based on the Marvell 88SE9230 Chipset.

 

I have drives connected to all of these controllers (in addition to the 6x southbridge SATA ports and a SiL based PCIe 2x port SATA card)

 

Booting unRAID 6b5a, all drives are accessible

 

Booting unRAID 6b6, only drives not attached to Marvell controllers are accessible.

 

During boot, the screen fills with errors similar to the following, with many entries displayed for each of the controller device ids;

 

AMD-Vi: Event logged [iO_PAGE_FAULT device=01:00.0 domain=0x0017 address=0x0000000000001000 flags=0x0000]

 

 

This can be solved by switching off IOMMU in bios, but that of course impacts virtualisation & device passthrough.

 

There is a fix for this issue in the form of a kernel patch. Full issue discussion and details on bugzilla here;

 

https://bugzilla.kernel.org/show_bug.cgi?id=42679

 

Here's the direct link to the patch;

 

https://lkml.org/lkml/2014/5/22/685

 

 

This is not an unRAID issue but rather a Kernel 3.15 (and possibly earlier) issue. I've encountered in on OpenSuSe as well on the same machine. (it's actually a hardware issue with the Marvell controller which misbehaves by addressing memory reserved for IOMMU)

 

 

Ideally, the above patch should be applied to the kernel or users with several versions of Marvell SATA controllers will be out of luck (and like me find their controllers broken if upgrading to 6b6)

 

I'm happy to test pre-release versions if it helps LimeTech.

 

Peter

I think Tom and I talked about this earlier as well.  Will double check but this MAY have already been addressed in our current development.

Just updated to b6 and I noticed that the CPU temperature sensors no longer report the temperature. Not sure if this is an unRAID issue or an unMENU issue but thought I would post here. They worked in b5a.

Jul 8 17:24:13 unmenu[3086]: No sensors found!

Jul 8 17:24:13 unmenu[3086]: Make sure you loaded all the kernel drivers you need.

Jul 8 17:24:13 unmenu[3086]: Try sensors-detect to find out which these are.

Just updated to b6 and I noticed that the CPU temperature sensors no longer report the temperature. Not sure if this is an unRAID issue or an unMENU issue but thought I would post here. They worked in b5a.

 

Jul 8 17:24:13 unmenu[3086]: No sensors found!

Jul 8 17:24:13 unmenu[3086]: Make sure you loaded all the kernel drivers you need.

Jul 8 17:24:13 unmenu[3086]: Try sensors-detect to find out which these are.

if you just copied over the 6 beta 6 files to your unraid 5 stick than i would start disabling all packages you installed with unmenu as most of them are x86 packages

for your temperature you can try typing sensors in the terminal and see if that gives you an output

and then i guess a good soul will need to adapt that package in unmenu for x64

my output from the sensors command

movieraid

root@P8H67:~# sensors

No sensors found!

Make sure you loaded all the kernel drivers you need.

Try sensors-detect to find out which these are.

TVraid

root@R2D2:~# sensors

atk0110-acpi-0

Adapter: ACPI interface

Vcore Voltage:      +1.08 V  (min =  +0.80 V, max =  +1.60 V)

+3.3 Voltage:      +3.36 V  (min =  +2.97 V, max =  +3.63 V)

+5 Voltage:        +5.04 V  (min =  +4.50 V, max =  +5.50 V)

+12 Voltage:      +12.32 V  (min = +10.20 V, max = +13.80 V)

CPU FAN Speed:      2109 RPM  (min =  600 RPM, max = 7200 RPM)

CHASSIS1 FAN Speed:    0 RPM  (min =  600 RPM, max = 7200 RPM)

CHASSIS2 FAN Speed:  839 RPM  (min =  600 RPM, max = 7200 RPM)

POWER FAN Speed:    1068 RPM  (min =  600 RPM, max = 7200 RPM)

CPU Temperature:    +61.0 C  (high = +60.0 C, crit = +95.0 C)

MB Temperature:      +41.0 C  (high = +45.0 C, crit = +75.0 C)

you will probably be needing some package ...

Just updated to b6 and I noticed that the CPU temperature sensors no longer report the temperature. Not sure if this is an unRAID issue or an unMENU issue but thought I would post here. They worked in b5a.

 

Jul 8 17:24:13 unmenu[3086]: No sensors found!

Jul 8 17:24:13 unmenu[3086]: Make sure you loaded all the kernel drivers you need.

Jul 8 17:24:13 unmenu[3086]: Try sensors-detect to find out which these are.

Try modprobe coretemp.  You'll have to put it in your go script. If you want the rest of the sensors you'll have to do the sensors-detect then moprobe the sensor

Just updated to b6 and I noticed that the CPU temperature sensors no longer report the temperature. Not sure if this is an unRAID issue or an unMENU issue but thought I would post here. They worked in b5a.

 

Jul 8 17:24:13 unmenu[3086]: No sensors found!

Jul 8 17:24:13 unmenu[3086]: Make sure you loaded all the kernel drivers you need.

Jul 8 17:24:13 unmenu[3086]: Try sensors-detect to find out which these are.

 

if you just copied over the 6 beta 6 files to your unraid 5 stick than i would start disabling all packages you installed with unmenu as most of them are x86 packages

for your temperature you can try typing sensors in the terminal and see if that gives you an output

and then i guess a good soul will need to adapt that package in unmenu for x64

 

my output from the sensors command

 

movieraid

root@P8H67:~# sensors

No sensors found!

Make sure you loaded all the kernel drivers you need.

Try sensors-detect to find out which these are.

 

TVraid

root@R2D2:~# sensors

atk0110-acpi-0

Adapter: ACPI interface

Vcore Voltage:      +1.08 V  (min =  +0.80 V, max =  +1.60 V)

+3.3 Voltage:      +3.36 V  (min =  +2.97 V, max =  +3.63 V)

+5 Voltage:        +5.04 V  (min =  +4.50 V, max =  +5.50 V)

+12 Voltage:      +12.32 V  (min = +10.20 V, max = +13.80 V)

CPU FAN Speed:      2109 RPM  (min =  600 RPM, max = 7200 RPM)

CHASSIS1 FAN Speed:    0 RPM  (min =  600 RPM, max = 7200 RPM)

CHASSIS2 FAN Speed:  839 RPM  (min =  600 RPM, max = 7200 RPM)

POWER FAN Speed:    1068 RPM  (min =  600 RPM, max = 7200 RPM)

CPU Temperature:    +61.0 C  (high = +60.0 C, crit = +95.0 C)

MB Temperature:      +41.0 C  (high = +45.0 C, crit = +75.0 C)

 

you will probably be needing some package ...

I upgraded from unRAID 6b5a to 6b6 and the sensor command worked in unRAID 6b5a. I never installed a package before. I'll test playing around with the commands and see what happens.

 

Just updated to b6 and I noticed that the CPU temperature sensors no longer report the temperature. Not sure if this is an unRAID issue or an unMENU issue but thought I would post here. They worked in b5a.

 

Jul 8 17:24:13 unmenu[3086]: No sensors found!

Jul 8 17:24:13 unmenu[3086]: Make sure you loaded all the kernel drivers you need.

Jul 8 17:24:13 unmenu[3086]: Try sensors-detect to find out which these are.

 

if you just copied over the 6 beta 6 files to your unraid 5 stick than i would start disabling all packages you installed with unmenu as most of them are x86 packages

for your temperature you can try typing sensors in the terminal and see if that gives you an output

and then i guess a good soul will need to adapt that package in unmenu for x64

 

my output from the sensors command

 

movieraid

root@P8H67:~# sensors

No sensors found!

Make sure you loaded all the kernel drivers you need.

Try sensors-detect to find out which these are.

 

TVraid

root@R2D2:~# sensors

atk0110-acpi-0

Adapter: ACPI interface

Vcore Voltage:      +1.08 V  (min =  +0.80 V, max =  +1.60 V)

+3.3 Voltage:      +3.36 V  (min =  +2.97 V, max =  +3.63 V)

+5 Voltage:        +5.04 V  (min =  +4.50 V, max =  +5.50 V)

+12 Voltage:      +12.32 V  (min = +10.20 V, max = +13.80 V)

CPU FAN Speed:      2109 RPM  (min =  600 RPM, max = 7200 RPM)

CHASSIS1 FAN Speed:    0 RPM  (min =  600 RPM, max = 7200 RPM)

CHASSIS2 FAN Speed:  839 RPM  (min =  600 RPM, max = 7200 RPM)

POWER FAN Speed:    1068 RPM  (min =  600 RPM, max = 7200 RPM)

CPU Temperature:    +61.0 C  (high = +60.0 C, crit = +95.0 C)

MB Temperature:      +41.0 C  (high = +45.0 C, crit = +75.0 C)

 

you will probably be needing some package ...

 

I upgraded from unRAID 6b5a to 6b6 and the sensor command worked in unRAID 6b5a. I never installed a package before. I'll test playing around with the commands and see what happens.

Try this too: modprobe w83627ehf

If it doesn't work you can do: modprobe -r w83627ehf

Neither command "modprobe w83627ehf" or "modprobe -r w83627ehf" displays a result. The syslog says "Jul 9 10:05:52 kernel: w83627ehf: Found NCT6776F chip at 0x290"

Modprobe won't show a result unless there's an error.  Type sensors after. You can try modprobe w83627ehf or nct6776 or nct6775 then type sensors.  Also did modprobe coretemp work.  Should at least show processor temps.

Modprobe won't show a result unless there's an error.  Type sensors after. You can try modprobe w83627ehf or nct6776 or nct6775 then type sensors.  Also did modprobe coretemp work.  Should at least show processor temps.

As stated previously, try modprobe coretemp.

I had the exact same issue in unmenu, now it reports correctly (Intel setup here).

My go script looks like this (in case it helps you at all):

#!/bin/bash

# Start the Management Utility

/usr/local/sbin/emhttp &

# modprobe for each sensor

modprobe coretemp

# unMenu Startup

/boot/unmenu/uu

After typing "modprobe coretemp" I can now see the CPU temps in unMENU. Thanks for the help. Is this an issue with unMENU then and I should therefore add that command to my go script? or did something happen with the unRAID kernel and it could be fixed in the next beta?

My sensors displayed after entering both "modprobe w83627ehf" and "modprobe coretemp"

After typing "modprobe coretemp" I can now see the CPU temps in unMENU. Thanks for the help. Is this an issue with unMENU then and I should therefore add that command to my go script? or did something happen with the unRAID kernel and it could be fixed in the next beta?

It's an issue with 6b6. In the past modprobe coretemp was automatically enabled but for some reason it was not in this beta.

After typing "modprobe coretemp" I can now see the CPU temps in unMENU. Thanks for the help. Is this an issue with unMENU then and I should therefore add that command to my go script? or did something happen with the unRAID kernel and it could be fixed in the next beta?

It's an issue with 6b6. In the past modprobe coretemp was automatically enabled but for some reason it was not in this beta.

OK understood. Thanks dmacias!

I have a small bug to report:

xenman and rc.xendomains are failing to shutdown VM's that do not have PV drivers enabled, in my case a pfSense VM. This is very easy to fix, since we just need to enable the ACPI failover modifier, "-F":

In xenman, line 187; in /etc/default/xendomains, in lines 70 and 85.

My unraid menu pages are no longer working and the following line is at the bottom of my syslog:

Jul  6 18:40:16 Tower logger:        missing codepage or helper program, or other error

Jul  6 18:40:16 Tower emhttp: disk24 mount error: 32

I have no disk24.. I have disk 1 to 10 plus cachedrive..

I also notice that my user0 folder is gone...

Also the last line in the syslog is 4 days old... seems weird on itself..

Last thing I did was format my cache drive as btrfs

I've got an issue with my basic install of unRAID.  I've got a beta 6 installation on my xenserver 6.2.  On boot, it seems to get stuck at 'starting 'libvirtd' and even though this happens, unRAID is usable.  Even though it is usable, the a single cpu assigned seems to be stuck at 100%.  If I assign two CPUs then it is at 50% usage.  I don't know what is wrong and I have restarted the unRAID server multiple times now and nothing helps!

Anythoughts?

I've got an issue with my basic install of unRAID.  I've got a beta 6 installation on my xenserver 6.2.  On boot, it seems to get stuck at 'starting 'libvirtd' and even though this happens, unRAID is usable.  Even though it is usable, the a single cpu assigned seems to be stuck at 100%.  If I assign two CPUs then it is at 50% usage.  I don't know what is wrong and I have restarted the unRAID server multiple times now and nothing helps!

 

Anythoughts?

Are you running cache_dirs and starting it from the Go script by chance?

I've got an issue with my basic install of unRAID.  I've got a beta 6 installation on my xenserver 6.2.  On boot, it seems to get stuck at 'starting 'libvirtd' and even though this happens, unRAID is usable.  Even though it is usable, the a single cpu assigned seems to be stuck at 100%.  If I assign two CPUs then it is at 50% usage.  I don't know what is wrong and I have restarted the unRAID server multiple times now and nothing helps!

 

Anythoughts?

Could be because you are running unRAID as a guest and libvirt is a VM management tool.  We will be generating a bzroot release without any of the VM management components / dependencies.  Libvirt won't be present on that release.

Just to be clear though, we don't "officially" support running unRAID as a guest.  What I mean by that is we do not test our releases under different hypervisors before publishing a new release.  We don't do anything to intentionally prevent them from working and we have even gone so far as to include driver support for some popular ones, but again, that's as far as we go.  Just wanted to set proper expectations.

I have been having some strange issues with Mac connectivity.  In 5.X, I would get a posix write error running makemkv writing to a SMB share.  I switched over to NFS and everything seemed to work fine. 

I updated unRaid to 6.x early on to see if the updated samba would fix the issue.  I found if I turned off the "acl allow execute always = Yes" I can write fine, but turning that back on causes the posix error again.  I have also tested with using NFS like I used in 5.x, but I found that after a few days to a week, directories started disappearing on the NFS mount (they were physically still there and did show up using SMB), and eventually i would start to see stale NFS messages.  If I remounted the share, it would be back to normal for a period of time.  I tried using ver 3,4 and got the same behavior.

I haven't tried AFP yet on 6, I was waiting for the update.

Anyone with a btrfs cache drive seeing a slow down in a move from cache to array cache.

 

e.g. if I move a file from "/mnt/cache/download" to "/mnt/user/tv" the move only runs at say 100MB/s. That sounds fast but when essentially it is actually just renaming the file path to /mnt/cache/tv" it is very slow, it should be instant.

are you doing this from a script?  Something you can modify to test for the actual location of a share? And of course in this case since you know it is a cache share just go ahead and always use /mnt/cache instead of /mnt/user  [shrug]

 

Seems that might be your most likely path to goodness in the short term.  I think it would require a change to mv and not fuse, but I'm out of my depth and just guessing.

 

Actually that is a rather clever idea although I always prefer a fix for all rather than a fix for just me.

 

Seems like an area of refinement assuming there are no technology hurdles stopping it.

 

Update: altered my scripting to do the FUSE part itself. What was fast is now instant. Still think this is something that should happen automatically

If I could present an alternative view (stuff you already know though) ...

The computer industry has been moving for a long time and for many reasons toward device and object independence, so that storage can be addressed in portable and secure ways, without any knowledge of the underlying physical attributes (I'm really rusty on the correct terminology).  Accessing drive storage is generally through a path that partially or completely hides the nature of the storage and its location.  It could be a local hard drive, SSD, removable flash disk, optical, RAM disk, networked or cloud storage.  By doing this, we can have very different ownership, security, and access controls on every part of the path and/or the physical storage itself.  All stuff you know ...

What you are asking for though, circumvents this.  The idea of the UnRAID User Shares is consistent with the above principles, providing a path that both hides the physical attributes and allows separate security and access controls.  You aren't *supposed* to know where anything is stored, including whether it's on a common physical device.  Paths that look different are supposed to be treated as very different.  A tool that could peek below these security bounds could potentially open a security hole.

Side note:  Total Commander (a Windows tool) for Copy/Move performance reasons has an option to specify that certain drive letters are actually on the same physical drive, because Windows correctly hides that fact.  (I imagine they do that partly because they know that copies on the same drive can use the drive's own buffering and cache.)

And similarly, you at a high level may know that 2 paths are actually physically the same.  So you may be able to create a high level tool that intercepts certain paths and rewrites one of them to conform to a known path synonym, for improved performance (as you did).  You don't want to change FUSE or mv, but it would be safe to introduce a tool above mv that intercepted and rewrote paths for mv.

Haven't seen anyone mention this on the thread so here goes.

 

Updating from Beta4.

1. Copied the 4 files as mention on the readme.txt file (bzimage, bzroot, xen, readme.txt)

2. Start Unraid + Xen, everything works fine, no issues whatsoever, everything as expected including an ArchVM

3. Reboot

4. Start Unraid alone (no Xen)

5. Get error messages upon starting and then system reboots/shutdown.

 

Here are a few pictures of where it hangs up/shutsdown/reboots. These are the most common errors but sometimes it just reboots at random or hangs at a certain line, it's not always the same:

 

On these 2 errors, it simply hangs:

[a picture of a normal startup]

 

[another picture of a normal startup]

 

On this one it reboots:

 

[a picture of a kernel panic]

 

After getting these errors, I got a different USB stick and used it to test a clean install of UnraidBeta6 and got exactly the same results. Unraid+Xen works perfectly fine, but Unraid by itself doesn't. Everything worked fine under the Unraid beta 4, including Unraid by itself. There were no hardware changes between the 2 betas.

Your first 2 pictures show no errors at all, and display the normal startup log entries at different points of the startup.  The third one does show a 'panic', and so we know something important crashed, but not much more.  The panic is evidence that the kernel at least detected a crash, and still had sufficient control to report it, and reboot.  The hangs after the first 2 pictures were apparently so complete that the kernel was not able to report anything.  What is notable is that all 3 are clearly different, probably at different startup points, and with differing behavior.  That normally points to a memory problem.  Since you are sure that the system works after booting other versions, and only fails with this version, I suspect you will be extremely doubtful of a memory problem, but memory is a very strange beast sometimes.  It is still possible that something in the way a particular program or OS loads may trigger a memory problem, which is the reason that Memtest has all of those extra memory tests.  I fully agree your issue may not be memory related, but you really should run Memtest overnight just to make sure.  Memory is still the most likely cause when the crashes are so different.

One other remote possibility is heat, perhaps CPU or other chipset overheating?

A troubleshooting tip - a picture at a crash/hang like yours may or may not show any clues, but you can compare it with a copy of a recent syslog or dmesg info, and determine what normally should have happened next.  What you can see on the screen is what has already happened and is complete.  What is currently processing, and therefore potentially a cause of the crash, is what would show *next* in the syslog or dmesg info.  The info should be roughly the same as what is on the screen, and *might* provide a clue as to what did not start or complete successfully.

Experienced a hang on shutdown ...

I didn't realize a download was occurring in a Docker container when I hit the stop array button.

The download finished and began to copy it to the array before docker came down.

unRAID is hung trying to stop the array.  Last thing is said was "syncing filesystems".

I ran Weebo's powerdown script that it took the server down. No parity check ensued on reboot.

Is this "normal". In the future should I be manually stopping the dockers before shutting down the array?

Quick question, and apologies in advance if this has been answered already (I found some hits searching in the b3 thread but no resolution).

In relation to the MAC address problem that was reported in B3, is this still an issue?

I have a Win2008R2 DHCP server, and every time I reboot it seems to "change" the MAC address.

My initial installation had an address of 657468300001000110eecd5a10c27b4cacab (10c27b1cacab is correct)

Two reboots later, it is 65746830000100011b575a5410c27b1cacab

I also booted on two fresh USB keys to extract the GUIDs, and each of those had different IP addresses too.

Is there a setting I can change anywhere?