unRAID Server Release 6.2.0-beta21 Available


Recommended Posts

I have a few warnings in my logs that I just wanted to put out there. May help with beta 21 issues. Diagnostics attached. Cheers.

 

May 23 09:45:58 Core kernel: ACPI: Early table checksum verification disabled

May 23 09:45:58 Core kernel: spurious 8259A interrupt: IRQ7.

May 23 09:45:58 Core kernel: ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20150930/dswload-210)

May 23 09:45:58 Core kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20150930/psobject-227)

May 23 09:45:58 Core kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20150930/tbxfload-193)

May 23 09:45:58 Core kernel: ACPI Error: 1 table load failures, 8 successful (20150930/tbxfload-214)

May 23 09:45:58 Core kernel: ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20150930/hwxface-580)

May 23 09:45:58 Core kernel: ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150930/hwxface-580)

May 23 09:45:58 Core kernel: acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM

May 23 09:45:58 Core kernel: floppy0: no floppy controllers found

May 23 09:45:58 Core kernel: ACPI Warning: SystemIO range 0x000000000000F040-0x000000000000F05F conflicts with OpRegion 0x000000000000F040-0x000000000000F04F (\_SB_.PCI0.SBUS.SMBI) (20150930/utaddress-254)

May 23 09:46:01 Core rpc.statd[1732]: Failed to read /var/lib/nfs/state: Success

May 23 09:46:37 Core avahi-daemon[8661]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!

 

ALL of the messages you have isolated are completely normal, completely typical, often found in almost all syslogs, and have been for many unRAID releases and kernel versions.  Nothing to worry about.  That "spurious 8259A interrupt: IRQ7" is how I identify a motherboard based on nVidia chipsets, has been for a long time, whether it's identified as nVidia or nForce or not.

 

ACPI issues are very common.  Most motherboard makers are primarily interested in cleaning up their BIOS for Windows, and once Windows is happy, it's generally a low priority whether you clean up anything else for Linux or other OS.  And Linux has done an exceptional job in recognizing and working around these issues.  The fact you are seeing the messages means the kernel detected the issue and handled it as best it could, almost always making them harmless.  You can try updating your BIOS, sometimes removes a few of the messages.  And sometimes a newer kernel will better handle them.

 

The other miscellaneous messages are equally common.

 

Here's another example of the kernel's ability to detect and work around the issues it finds -

Apr 27 04:11:06 Archangel kernel: pcieport 0000:00:02.0: AER: Corrected error received: id=0010
Apr 27 04:11:06 Archangel kernel: pcieport 0000:00:02.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0010(Receiver ID)
Apr 27 04:11:06 Archangel kernel: pcieport 0000:00:02.0:   device [8086:2f04] error status/mask=00000080/00002000
Apr 27 04:11:06 Archangel kernel: pcieport 0000:00:02.0:    [ 7] Bad DLLP              
Apr 27 21:06:31 Archangel kernel: pcieport 0000:00:03.0: AER: Uncorrected (Non-Fatal) error received: id=0018
Apr 27 21:06:31 Archangel kernel: pcieport 0000:00:03.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=0018(Requester ID)
Apr 27 21:06:31 Archangel kernel: pcieport 0000:00:03.0:   device [8086:2f08] error status/mask=00004000/00000000
Apr 27 21:06:31 Archangel kernel: pcieport 0000:00:03.0:    [14] Completion Timeout     (First)
Apr 27 21:06:31 Archangel kernel: pcieport 0000:00:03.0: broadcast error_detected message
Apr 27 21:06:31 Archangel kernel: pcieport 0000:00:03.0: broadcast mmio_enabled message
Apr 27 21:06:31 Archangel kernel: pcieport 0000:00:03.0: broadcast resume message
Apr 27 21:06:31 Archangel kernel: pcieport 0000:00:03.0: AER: Device recovery successful

"AER: Corrected error received" shows it detected an issue, and fixed it.

"AER: Uncorrected (Non-Fatal) error received" shows it detected it, didn't fix it, but decided it wasn't important.

"AER: Device recovery successful" shows problems found, problems fixed (or worked around).

And these are just the ones it has decided to tell you about.

 

Our kernel is an amazing thing.  It's probably significantly larger than it could have been, just to work around all the bugs and inconsistencies in so many motherboard BIOS's and device drivers and hardware defects, and the ambiguities in most standards.

 

Thanks for the info Rob, you have put my mind at rest! So far I'm loving unraid, great software!

 

:)

Link to comment
  • Replies 545
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

 

Hey bigjme, I was wondering since I hadn't seen any update about this if downgrading the drivers had fixed your issues? I'm having literally the same error myself. I only just now found it though as I hadn't ever really stress tested my system till just the other day. I tried running 2 VMs (both in OVMF) with my 960s passthroughed to them. I wanted to see what she could do, so I opened up multiple games, movies and web videos, but instead found that I can reliably recreate the error you described in a similar manner. VM locks up but shows paused in unraid and cant be resumed just as you described. I'll check out using the 362 drivers, but thought I would ask you first since you initiated it.

 

Also, similar to your other post (and a few others here), I also have the "samba lockup issue" when I transfer a larger amount of files between the shares. Not knowing much of anything about how Samba works (only vaguely that it has to do with file sharing) I'll note that this only seems to happen with transfers from inside the windows VMs to the unraid shares (which I think is the function of samba if I'm not mistaken). However, if I SSH in and move stuff around the shares via mc, I've not had any issues.

 

EDIT-- I found your post on the nvidia forum, and the issue that they are having is being reported as still causing problems with the newest driver set 365.19. Installing 362 now and see how she fares after that.

 

The downgrade did indeed resolve my issue, I haven't shut down my system in a while to test the samba lockup issue but I can safely say my vms haven't had any lockups in rather a while

 

I haven't updated to anything newer since - I must say that I haven't really stressed the system since other then 1 of the vms playing minecraft

 

I am due to start playing the new doom game which should give it a decent test soon

Link to comment

Will the final release of 6.2 allow for up to 45 data drives in order to work with the 45 Drives Storinator?

 

Why would it? The Storinator isn't a Lime Tech product...

6.2 supports something like 30 devices in the array, can't remember how many devices in a cache pool, and an unlimited number of devices (at least on the PRO version) unassigned (mountable via UD), so the net result is that you can max out a 45 drive storinator.
Link to comment

Will the final release of 6.2 allow for up to 45 data drives in order to work with the 45 Drives Storinator?

 

Why would it? The Storinator isn't a Lime Tech product...

6.2 supports something like 30 devices in the array, can't remember how many devices in a cache pool, and an unlimited number of devices (at least on the PRO version) unassigned (mountable via UD), so the net result is that you can max out a 45 drive storinator.

 

array of 28 data drives + 2 parity drives and a cache pool of up to 24 drives (if you want to know exact numbers).

 

Link to comment

Will the final release of 6.2 allow for up to 45 data drives in order to work with the 45 Drives Storinator?

 

Why would it? The Storinator isn't a Lime Tech product...

6.2 supports something like 30 devices in the array, can't remember how many devices in a cache pool, and an unlimited number of devices (at least on the PRO version) unassigned (mountable via UD), so the net result is that you can max out a 45 drive storinator.

 

Correct, but my thoughts are 45 storage drives + 8 caching drives.

Link to comment

Also very curious about IGD passthrough / iGVT-g / KVMGT or what it is now officially called. Will this make the 6.2 release? Is it available in this beta already can anyone confirm?

 

Desperate want to try running unRAID on a NUC i5 with a 512GB SSD and a 2TB HDD, all in the smallest fanless silent enclosure strapped to the back of my monitor. Call me crazy...

Link to comment

Very minor issue, but the log shows the following about spinning down drives:

 

May 24 20:18:04 MediaServer kernel: mdcmd (147): spindown 0
May 24 20:18:04 MediaServer kernel: mdcmd (148): spindown 5
May 24 20:18:04 MediaServer kernel: mdcmd (149): spindown 29
May 24 20:50:22 MediaServer kernel: mdcmd (150): spindown 2
May 24 21:22:17 MediaServer kernel: mdcmd (151): spindown 5
May 24 21:29:15 MediaServer kernel: mdcmd (152): spindown 0
May 24 21:29:16 MediaServer kernel: mdcmd (153): spindown 3
May 24 21:29:16 MediaServer kernel: mdcmd (154): spindown 29

 

I don't have a drive number 29.  I have six data drives, two parity disks, and a cache drive.

 

Just a numbering issue I suspect on the second parity drive.

Link to comment

Very minor issue, but the log shows the following about spinning down drives:

 

May 24 20:18:04 MediaServer kernel: mdcmd (147): spindown 0
May 24 20:18:04 MediaServer kernel: mdcmd (148): spindown 5
May 24 20:18:04 MediaServer kernel: mdcmd (149): spindown 29
May 24 20:50:22 MediaServer kernel: mdcmd (150): spindown 2
May 24 21:22:17 MediaServer kernel: mdcmd (151): spindown 5
May 24 21:29:15 MediaServer kernel: mdcmd (152): spindown 0
May 24 21:29:16 MediaServer kernel: mdcmd (153): spindown 3
May 24 21:29:16 MediaServer kernel: mdcmd (154): spindown 29

 

I don't have a drive number 29.  I have six data drives, two parity disks, and a cache drive.

 

Just a numbering issue I suspect on the second parity drive.

 

The first parity disk is numbered as 0 (lowest available number in the array), while the second parity disk is numbered as 29 (highest available number in the array). Data disks are numbered from 1 to 28.

 

 

Link to comment

Very minor issue, but the log shows the following about spinning down drives:

 

May 24 20:18:04 MediaServer kernel: mdcmd (147): spindown 0
May 24 20:18:04 MediaServer kernel: mdcmd (148): spindown 5
May 24 20:18:04 MediaServer kernel: mdcmd (149): spindown 29
May 24 20:50:22 MediaServer kernel: mdcmd (150): spindown 2
May 24 21:22:17 MediaServer kernel: mdcmd (151): spindown 5
May 24 21:29:15 MediaServer kernel: mdcmd (152): spindown 0
May 24 21:29:16 MediaServer kernel: mdcmd (153): spindown 3
May 24 21:29:16 MediaServer kernel: mdcmd (154): spindown 29

 

I don't have a drive number 29.  I have six data drives, two parity disks, and a cache drive.

 

Just a numbering issue I suspect on the second parity drive.

 

The first parity disk is numbered as 0 (lowest available number in the array), while the second parity disk is numbered as 29 (highest available number in the array). Data disks are numbered from 1 to 28.

 

Ok.  That would explain it.  Thanks.

Link to comment

Not sure if this bug has been discovered or not however I just noticed it. When I went into scheduler and chose 'custom' for schedule parity checks, and selected a day of the week, such as Sunday, it would not remember it and default to 'every day'. This caused two unscheduled parity checks on my server in the past two days.

Link to comment

Not sure if this bug has been discovered or not however I just noticed it. When I went into scheduler and chose 'custom' for schedule parity checks, and selected a day of the week, such as Sunday, it would not remember it and default to 'every day'. This caused two unscheduled parity checks on my server in the past two days.

 

Yeah this is known, and fixed in upcoming release.

 

Link to comment

 

Yeah this is known, and fixed in upcoming release.

 

Upcoming release???

 

I would put upcoming in the same category as soon....  ;D

release != final. Not affiliated with limetech, but I'm pretty sure they just mean the next beta that's currently cooking. Final release is still wishful thinking.
Link to comment

release != final. Not affiliated with limetech, but I'm pretty sure they just mean the next beta that's currently cooking. Final release is still wishful thinking.

 

Yeah, i figured it referred to a beta release.  I get the "when it's ready" mentality, but given this loyal fanbase I would hope that the Lime folks would be a little more open as to what they're working on.

Link to comment

Don't take offence to it.  Communications during beta stages are often sparse.  I've always presumed it's because they're a small team and time is spent on the actual coding rather than telling the great unwashed what's happening. 

 

To be honest the forum uprisings and general disquiet I find amusing and part of the fun of the beta stages...

Link to comment

Don't take offence to it.  Communications during beta stages are often sparse.  I've always presumed it's because they're a small team and time isr spent on the actual coding rather than telling the great unwashed what's happening. 

 

To be honest the forum uprisings and general disquiet I find amusing and part of the fun of the beta stages...

 

I don't take offense to it.  Companies pick where they are on the openness spectrum: Apple (we'll tell you what you need to know when you need to know it and you WILL wait and like it)  --- to the new Microsoft (here's everything we're working on please try it and tell us what you think).  I just prefer more openness is all -- particularly when I'm doing it for part solution and part hobby as I'm sure many of us are.

Link to comment
Guest
This topic is now closed to further replies.