unRAID Server Release 5.0-beta12a Available


limetech

Recommended Posts

  • Replies 383
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Much as I would love to see an official 5.0 release, I personally still don't think it's quite ready. Tom mentioned in the release notes for 12a that he's tried to tweak something to resolve the BLK_EH_NOT_HANDLED errors that several of us are seeing.

 

In my experience, this issue still isn't fixed, and causes the server to become unresponsive (at least from the UI point of view) and all of the MV8 connected drives to be in-accessible from the terminal / ssh when it happens. As far as I can see, the only solution is a hard reset, which isn't a nice thing to have to do. Again, in my experience, it takes about 2 days for this issue to manifest.

 

As before, I'm attaching a few complete sys logs that show the problem; some from beta11, some from beta12, and some from beta12a.

 

Extracting all of the BLK_EH_NOT_HANDLED lines from the logs, there doesn't seem to be any pattern, and using Google I wasn't able to find any information on what the (presumably) Hex codes for 'command' and 'task' relate to.

 

Beta 11
Aug 16 09:14:21 unRAID kernel: sas: command 0xd9fa9e40, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED
Aug 16 10:27:13 unRAID kernel: sas: command 0xf77af6c0, task 0xdf71c140, timed out: BLK_EH_NOT_HANDLED
Aug 16 13:30:37 unRAID kernel: sas: command 0xf7661240, task 0xdf71db80, timed out: BLK_EH_NOT_HANDLED
Aug 16 13:53:49 unRAID kernel: sas: command 0xf6ded6c0, task 0xdf71ca00, timed out: BLK_EH_NOT_HANDLED
Aug 16 15:42:56 unRAID kernel: sas: command 0xf75efcc0, task 0xdf4dd2c0, timed out: BLK_EH_NOT_HANDLED
Aug 16 23:14:38 unRAID kernel: sas: command 0xf6fc6a80, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED
Aug 17 02:32:09 unRAID kernel: sas: command 0xf6fc6480, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED
Aug 17 05:35:40 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED
Aug 17 06:05:34 unRAID kernel: sas: command 0xcdf13f00, task 0xdf71cf00, timed out: BLK_EH_NOT_HANDLED
Aug 17 18:11:49 unRAID kernel: sas: command 0xd9f8f9c0, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED
Aug 17 19:11:08 unRAID kernel: sas: command 0xd9f8fd80, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED
Aug 17 20:47:38 unRAID kernel: sas: command 0xcdf13b40, task 0xdf71d680, timed out: BLK_EH_NOT_HANDLED
Aug 18 00:40:51 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71cdc0, timed out: BLK_EH_NOT_HANDLED
Aug 18 05:07:55 unRAID kernel: sas: command 0xcdf13d80, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED
Aug 18 18:16:28 unRAID kernel: sas: command 0xf75ef780, task 0xdf4dd7c0, timed out: BLK_EH_NOT_HANDLED
Aug 19 10:30:41 unRAID kernel: sas: command 0xf75ef600, task 0xdf4dc280, timed out: BLK_EH_NOT_HANDLED
Aug 19 17:48:24 unRAID kernel: sas: command 0xcdf133c0, task 0xdf71c3c0, timed out: BLK_EH_NOT_HANDLED
Aug 20 05:07:11 unRAID kernel: sas: command 0xf6fc6300, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED
Aug 20 08:17:25 unRAID kernel: sas: command 0xcdf13f00, task 0xdf71d2c0, timed out: BLK_EH_NOT_HANDLED
Aug 20 20:13:56 unRAID kernel: sas: command 0xcdf13e40, task 0xdf71d400, timed out: BLK_EH_NOT_HANDLED
Aug 20 20:42:10 unRAID kernel: sas: command 0xf754f000, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED
Aug 20 23:10:46 unRAID kernel: sas: command 0xcdf13000, task 0xdf71d900, timed out: BLK_EH_NOT_HANDLED
Aug 21 02:18:10 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71cc80, timed out: BLK_EH_NOT_HANDLED
Aug 21 05:37:45 unRAID kernel: sas: command 0xcdc47540, task 0xdf71e500, timed out: BLK_EH_NOT_HANDLED
Aug 21 07:10:02 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4ddb80, timed out: BLK_EH_NOT_HANDLED
Aug 21 18:08:19 unRAID kernel: sas: command 0xf75eff00, task 0xdf4dd900, timed out: BLK_EH_NOT_HANDLED
Aug 21 23:32:21 unRAID kernel: sas: command 0xf75ef480, task 0xdf4dcf00, timed out: BLK_EH_NOT_HANDLED
Aug 22 13:19:01 unRAID kernel: sas: command 0xd0c2bb40, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED
Aug 22 15:08:13 unRAID kernel: sas: command 0xcdf36d80, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED
Aug 23 00:08:40 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED
Aug 23 04:12:11 unRAID kernel: sas: command 0xf75efc00, task 0xdf4dd7c0, timed out: BLK_EH_NOT_HANDLED
Aug 23 10:26:29 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4dc280, timed out: BLK_EH_NOT_HANDLED
Aug 23 15:32:48 unRAID kernel: sas: command 0xf75eff00, task 0xdf4dc3c0, timed out: BLK_EH_NOT_HANDLED
Aug 23 16:45:50 unRAID kernel: sas: command 0xf75ef180, task 0xdf4dcc80, timed out: BLK_EH_NOT_HANDLED
Aug 24 04:40:28 unRAID kernel: sas: command 0xcdf13180, task 0xdf71cc80, timed out: BLK_EH_NOT_HANDLED
Aug 24 07:31:50 unRAID kernel: sas: command 0xcdc47480, task 0xdf71ea00, timed out: BLK_EH_NOT_HANDLED
Aug 24 14:04:09 unRAID kernel: sas: command 0xf6f70b40, task 0xdf4ce140, timed out: BLK_EH_NOT_HANDLED
Aug 24 17:13:11 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71c280, timed out: BLK_EH_NOT_HANDLED
Aug 25 00:19:54 unRAID kernel: sas: command 0xcdf13b40, task 0xdf71cf00, timed out: BLK_EH_NOT_HANDLED
Aug 25 08:20:32 unRAID kernel: sas: command 0xcdc479c0, task 0xdf71f180, timed out: BLK_EH_NOT_HANDLED
Aug 25 09:52:37 unRAID kernel: sas: command 0xcdc470c0, task 0xdf71e280, timed out: BLK_EH_NOT_HANDLED
Aug 25 12:22:13 unRAID kernel: sas: command 0xcdf13240, task 0xdf71d180, timed out: BLK_EH_NOT_HANDLED
Aug 25 16:00:00 unRAID kernel: sas: command 0xf6f70b40, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED
Aug 25 20:01:00 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71db80, timed out: BLK_EH_NOT_HANDLED
Aug 27 05:08:45 unRAID kernel: sas: command 0xf75ef840, task 0xdf4dcf00, timed out: BLK_EH_NOT_HANDLED
Aug 27 07:02:40 unRAID kernel: sas: command 0xf6f459c0, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED
Aug 27 16:11:21 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4dd400, timed out: BLK_EH_NOT_HANDLED
Aug 27 16:11:51 unRAID kernel: sas: command 0xf75ef000, task 0xdf4dd680, timed out: BLK_EH_NOT_HANDLED
Aug 27 21:02:06 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71d2c0, timed out: BLK_EH_NOT_HANDLED
Aug 28 04:38:11 unRAID kernel: sas: command 0xcdf36f00, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED
Aug 28 07:06:22 unRAID kernel: sas: command 0xf75ef840, task 0xdf4dc8c0, timed out: BLK_EH_NOT_HANDLED

Beta 12
Sep  1 03:11:26 unRAID kernel: sas: command 0xdf8c1180, task 0xf47d8780, timed out: BLK_EH_NOT_HANDLED
Sep  1 06:03:19 unRAID kernel: sas: command 0xdf95f0c0, task 0xf467f2c0, timed out: BLK_EH_NOT_HANDLED

Sep 10 18:42:59 unRAID kernel: sas: command 0xeface180, task 0xdf86fcc0, timed out: BLK_EH_NOT_HANDLED
Sep 11 23:00:34 unRAID kernel: sas: command 0xf4752600, task 0xdf826500, timed out: BLK_EH_NOT_HANDLED

Beta 12a
Sep 13 23:29:33 unRAID kernel: sas: command 0xdf872cc0, task 0xdfb04280, timed out: BLK_EH_NOT_HANDLED
Sep 14 12:56:14 unRAID kernel: sas: command 0xda60d240, task 0xdf87c780, timed out: BLK_EH_NOT_HANDLED

[email protected]

[email protected]

[email protected]

[email protected]

Link to comment

Hello,

 

just updated fro, 5.10 to 5.12b.

 

Reason: 5.10 did not recognice my new AOC-SAS2LP-MV8. (5.12d does)

 

Feedback after on day:

 

did a parity check (with 115MB/sec) but emhttp died after fisnish the check. Telnet worked, but "powerdown" did not work.

 

Overall: array works.

 

Just for info...

Link to comment

Can somone please help me with my upgrade from 5b6a to 5b12a.  I replaced the correct files on the flash and the webgui loaded.  The problem is that unraid sees all my WD 2tb drives as unknown formats.  I have included the first part of my vary large syslog, at the end of the first part it looks like command keep on reapeating and continus throw most of the last part of the sys log.  Any help would be wonderful.

Any Ideas?

 

Additional Info:

Supermicro MBD-X8SIL-F-O with an i3 and 4gb of Kingston memory

Supermicro AOC-SASLP-MV8 SAS card

Corsair Professional Series HX750

 

 

Post the entire syslog. Zip it.

Link to comment

Hello,

just updated fro, 5.10 to 5.12b.

Reason: 5.10 did not recognice my new AOC-SAS2LP-MV8. (5.12d does)

Feedback after on day:

did a parity check (with 115MB/sec) but emhttp died after fisnish the check. Telnet worked, but "powerdown" did not work.

Overall: array works.

Just for info...

WHAT INFO? INFO IS AN ENTIRE SYSLOG ATTACHED!

 

Please help Tom out by posting the entire syslog.

 

If some have not noticed, Tom's tone/stance on not posting a complete syslog with your post will fall on deaf ears. Its hard enought to do what he is doing in 5beta, without a syslog what could he possible do to improve/fix anything.

 

PLEASE if you run into an issue, POST your entire SYSLOG. There are many experienced forum members that read through them as well and help.

Link to comment

I'm also getting the BLK_NOT_HANDLED errors.  Have tried running b10-b12a but these errors persist.

 

My setup:

X9SCM-F-O

i3-2100

Norco 4224

2 x SASLP-MV8

8gb RAM

Corsair TX750

 

My problem is basically the same as everyone else reporting this error.  I have tried preclearing a new 3tb Hitachi 5400 and the BLK error rears it's head within a couple minutes.  That drive might be DOA though so maybe not related.  I've also tried preclearing a 2tb Hitachi 7200 that I've used in my test runs of Unraid with no problems and with this drive the system will run for a few hours before the BLK errors happen.  Obviously this only happens with drives connected to either of the SASLP.  I've swapped cards and pci slots but to no prevail.  I've also checked all power connections and ran with only power to the drives connected to the SASLP and still have same errors.

 

Attached is my syslog from last night with the errors.

syslog.zip

Link to comment

just noticed the following error in my system log

 

Sep 17 22:22:29 storage2 kernel: handle_stripe read error: 844899128/0, count: 1
Sep 17 22:22:29 storage2 kernel: md: disk0 read error
Sep 17 22:22:29 storage2 kernel: handle_stripe read error: 844899136/0, count: 1
Sep 17 22:22:29 storage2 kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Sep 17 22:22:29 storage2 kernel: ata3.00: BMDMA stat 0x66
Sep 17 22:22:29 storage2 kernel: ata3.00: failed command: READ DMA EXT
Sep 17 22:22:29 storage2 kernel: ata3.00: cmd 25/00:00:87:23:5c/00:04:32:00:00/e0 tag 0 dma 524288 in
Sep 17 22:22:29 storage2 kernel:          res 51/84:87:00:00:00/84:27:00:00:00/e0 Emask 0x30 (host bus error)
Sep 17 22:22:29 storage2 kernel: ata3.00: status: { DRDY ERR }
Sep 17 22:22:29 storage2 kernel: ata3.00: error: { ICRC ABRT }
Sep 17 22:22:29 storage2 kernel: ata3: soft resetting link
Sep 17 22:22:29 storage2 kernel: ata3.00: configured for UDMA/33
Sep 17 22:22:29 storage2 kernel: ata3.01: configured for UDMA/133
Sep 17 22:22:29 storage2 kernel: ata3: EH complete

 

here is the syslog.  Is this something to be concerned about?

 

It's a plus system with a Parity, Cache, disk1 & disk 2. I can provide the HDD info if needed

 

Thanks

 

Edit - checked my sata cabling and rebooted the server and all is well. no errors in the syslog after the re-cabling.

Link to comment

Has anyone else had this issue with 12a not even booting, bzroot just hangs with about 12-13 rows of dots.

All previous beta's have worked fine for me.

 

Syslog for beta 12 attached

 

Thanks

 

Stephen

 

Hi,

 

I am having exactly the same problem with beta 12a. Loading bzroot just hangs with about 12-13 rows of dots.

Beta 12 works fine and all previous betas have also.

Syslog for beta 12 attached

 

Many thanks

syslog.txt

Link to comment

Has anyone else had this issue with 12a not even booting, bzroot just hangs with about 12-13 rows of dots.

All previous beta's have worked fine for me.

 

Syslog for beta 12 attached

 

Thanks

 

Stephen

 

Hi,

 

I am having exactly the same problem with beta 12a. Loading bzroot just hangs with about 12-13 rows of dots.

Beta 12 works fine and all previous betas have also.

Syslog for beta 12 attached

 

Many thanks

 

 

Save you config directory and reformat the flash. Follow insturctions for install to a new flash drive. After it boots successfully, replace the config directory and reboot.

Link to comment

Can somone please help me with my upgrade from 5b6a to 5b12a.  I replaced the correct files on the flash and the webgui loaded.  The problem is that unraid sees all my WD 2tb drives as unknown formats.  I have included the first part of my vary large syslog, at the end of the first part it looks like command keep on reapeating and continus throw most of the last part of the sys log.  Any help would be wonderful.

Any Ideas?

 

Additional Info:

Supermicro MBD-X8SIL-F-O with an i3 and 4gb of Kingston memory

Supermicro AOC-SASLP-MV8 SAS card

Corsair Professional Series HX750

 

 

Post the entire syslog. Zip it.

 

I did, here it is again

System_Log.zip

Link to comment

On 12a, I added two WD EARS and now my array won't start, it just sits in Starting .... , unmenu says its started but I know that's not really ready for 5.0 yet.  The EARS have not even been added to the array.  I have rebooted stopping what I can via cmd line before.  I've attached a syslog nothing really stands out.

 

Thanks for the help -

 

-Dave

 

EDIT: Got it to start by removing all the plugins - (couchpotato, sickbeard, sab, dyndns) rebooted via cmd line, then reboot via the GUI, array started.

syslog.txt

Link to comment

 

We have seen quite some cases with the "BLK_NOT_HANDLED" situation. A VERY annoying one.

I still have this issue and for me the whole unRAID setup is worthless at the moment (Pro license, B12A)

 

We have also seen users providing their FULL syslogs. Where's the support on this? I hope it's being looked at in the 'back office'. 

I work with developers everyday and I understand that at some point you will make rules in order to give quality feedback.

 

Just now I am performing a Preclear run for all my brand new disks (13x2.0TB, Hitachi -HDS723020BLA642) and will try again when this finishes (takes forever  :-\)

 

What's the status? Thanks  ::)

 

Link to comment

 

We have seen quite some cases with the "BLK_NOT_HANDLED" situation. A VERY annoying one.

I still have this issue and for me the whole unRAID setup is worthless at the moment (Pro license, B12A)

 

 

I am sure you know that the b in 5.0b12a indicates it is a beta. If you want a stable release that is not worthless, there is 4.7 for you. If you insist on running a beta you will have to accept the development pace. I am a bit perplexed by many users here treating the 5 beta as a software for their production rigs, and demanding instant solutions for problems that is clearly a part of the beta process. I am sure Tom will update with a new beta as soon as he have a probable solution to these problems.

 

Sorry for the rant, but just couldn't help myself. I am also eagerly awaiting the finished 5.0 and running the beta on my server. But it is a beta, not the final.

 

/Lars Olof

Link to comment

 

We have seen quite some cases with the "BLK_NOT_HANDLED" situation. A VERY annoying one.

 

Indeed .. and I'm hoping that the underlying cause is the same one which is causing me problems with the mpt2sas driver, which produces "attempting task abort" messages in the syslog.  Certainly, some of the circumstances appear to be similar (ie heavy read activity such as during a preclear).

Link to comment

Not that anything is 'owed' to anyone that is running beta--but an update or eta for next revision 12b, 13, whatever it may be, would be nice.  As the last poster(s) indicated, it is beta--so, whatever changes have been made in an attempt to stabilize the BLK issue, network driver issues, I'm sure everyone would be willing to continue to test and report whatever progress has been made in the last couple weeks.

 

For me, I reduced my server to 1 supermicro sas card, added 2 adaptec cards, moved to a different case (avoiding the norco 4224 backplane) and tried again.  With two supermicro sas cards in, I still saw the issues.  When I removed it, and added the adaptec card(s) and used onboard--I've yet to see that lockup issue.  I don't know if it's an issue with the supermicro board (motherboard/pcie) or the sas cards, or the drivers/unraid... but seems it likes one card a lot better than multiple.  For now it's stable for me. 

 

I've decided to try building it into a full release of slack again--I really need a full linux box and without the ability to do the CPIO/zcat mod to  permanently add packages, kindof a must for me.

Link to comment

 

We have seen quite some cases with the "BLK_NOT_HANDLED" situation. A VERY annoying one.

I still have this issue and for me the whole unRAID setup is worthless at the moment (Pro license, B12A)

.

.

.

What's the status? Thanks  ::)

 

 

The first line on the release notes page reads as follows....

 

Latest beta is: 5.0-beta12a

These release notes refer to installation and upgrade instructions for a major unRAID Server version change. Please be aware that all measures have been taken to ensure data integrity, but this is beta software - use at your own risk.

 

What's worthless is providing feedback the does not further development of the product, touting credentials, oh and the best of all what you have paid for..... It's BETA, for someone that works with developers, you surely understand what beta software means and that providing feedback by noting something to be "worthless" is not something they would smile upon. As stated in posts above, the stable release is 4.7.

 

J

Link to comment

@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

@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.

 

 

See other threads on this forum, it is confirmed that the AOC-SASLP-MV8 works fine with 3Tb disks.

 

edit: It seem the test was done using only one 3tb on the aoc-saslp-mv8 http://lime-technology.com/forum/index.php?topic=11183.msg109527#msg109527

 

on avsforums I found a couple of people who had no problems with 1 drive but did with multiple 3tb drives.

 

I will do some more research as my production unraid has a SASLP but I'm currently testing the beta on another server with 2 WD 3Tb drives.

Link to comment

Here's another "BLK_NOT_HANDLED" case on a Supermicro AOC-SASLP-MV8 card. Syslog attached (DHCP activity filtered).

 

No client file activity was involved other than looking at \\tower\flash when copying syslogs. Network activity was limited to telnet sessions.

 

Working up to the failure, I'd successfully precleared two Hitachis. I then started the WD EARS. The EARS is one that's shown errors after reaching a high LCC. When I left it, it had progressed beyond 50% of the pre-read dd. When I returned this morning the telnet window was dead. You can see the error at Sep 21 03:33:24. I'm guessing this was yet another drive response that exceeded mv_sas timing.

 

System load is stuck at about 6. Nothing interesting from top. /proc/interrupts shows mild continued activity for eth0 and maybe 5/sec for RES:

 

          CPU0       CPU1

 0:         24          0   IO-APIC-edge      timer

 1:          0          2   IO-APIC-edge      i8042

 9:          0          0   IO-APIC-fasteoi   acpi

12:          0          3   IO-APIC-edge      i8042

16:    1935052  151592570   IO-APIC-fasteoi   mvsas

17:          1          1   IO-APIC-fasteoi   ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3

18:         36        412   IO-APIC-fasteoi   ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7

19:       2179      87455   IO-APIC-fasteoi   ahci

40:         56       3210   PCI-MSI-edge      xhci_hcd

41:          0          0   PCI-MSI-edge      xhci_hcd

42:          0          0   PCI-MSI-edge      xhci_hcd

43:       4528     120995   PCI-MSI-edge      eth0

NMI:          0          0   Non-maskable interrupts

LOC:   25901602   25901554   Local timer interrupts

SPU:          0          0   Spurious interrupts

PMI:          0          0   Performance monitoring interrupts

IWI:          0          0   IRQ work interrupts

RES:  521564869 1075787243   Rescheduling interrupts

CAL:   10852373   10120174   Function call interrupts

TLB:      51680      47495   TLB shootdowns

TRM:          0          0   Thermal event interrupts

THR:          0          0   Threshold APIC interrupts

MCE:          0          0   Machine check exceptions

MCP:        864        864   Machine check polls

ERR:          0

MIS:          0

 

There's plenty of discussion/activity out there regarding this card and BLK_NOT_HANDLED problems, and on systems completely unrelated to unRAID other than being linux or FBSD. Rubbish driver?

 

Edit 9/23/2011 2:40pm:

Moved the borderline EARS drive to a MB SATA position. Precleared EARS drive successfully and then rebuilt parity while simultaneously transferring about 1TB to the empty EARS via rsync. Worked fine, if slow due to parallel operations. rsync speed on its own isn't bad at 20-40MB/s. This is using the on-board Realtek 8111E nic. So, I've hammered on it pretty well and things seem good so long as all drives on the AOC-SASLP-MV8 behave.

syslog_precleardie_2011-09-21.zip

Link to comment

It is Tom's prerogative to remain silent until he's ready to share.  I do not fault him for it.

 

I will say that in my opinion if task X takes 3 months to do, but you're regularly keeping stakeholders informed, they generally will be a lot happier than if task X takes 1.5 months, and there's nothing but silence during that time.

 

It's in our nature to want everything "now" true - the general availability of information can fill that "need" in the absence of the final product.

 

That's just my uneducated assessment.

 

This isn't exactly Tom's full time job - so there's only so much we can expect.  I'm sure he's pulling his hair out over some of these more difficult issues to resolve.  I wish him godspeed in doing so.

Link to comment

With regards to the AOC-SASLP-MV8 problems.

As I am new to Unraid, I started on the beta because the stable version didn't support my network card.

I have one of these sas cards in my system and got these blk errors so obviously you don't need two cards to get the errors.

 

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

 

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.