bungee91
-
Posts
744 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by bungee91
-
-
Was playing around with VMs on my crappy hardware, and had the system just up and reset on me. Not worried about this. I have cheap hardware.
But, upon restart the system did NOT start up a parity check. Fix Common Problems knew that it was an unclean shutdown (it handles this in its own way), but unRaid didn't realize it for some reason
I've had this same behavior on the last couple of beta's, think I mentioned it at that time.
Looking at the console at bootup I believe I also seen the entry for the dirty bit detected (or whatever it flags) on the USB drive, however no parity check when booted just "parity is valid".
Have not had to perform a force reset on this release however.
-
Thanks for the continued improvements!
I've added some requests, feel free to comment or ignore them entirely..
-
Are you using the downloadable iso for upgrade, or the upgrade wizard (GWX) for update?
If not the downloadable ISO, you'll want to switch to that.
For the 1-core selection, I believe core 0 is preffered.
How much ram is assigned to the VM? I would reduce this if you're passing an unnecessary amount during this upgrade (minimizing potential issues), 4-8GB is more than sufficient for this operation.
-
"Legacy USB support" has nothing to do with the boot settings ... that just determines the operating mode of the USB controller.
I'm glad he got this fixed, however this is not universally true.
While the legacy USB option is used to emulates a ps/2 or AT device when a USB mouse is used with an OS that dosen't support it (also can lead to issue when disabled getting into the BIOS), it can also disable a legacy non UEFI boot option.
I don't recall if my current board does this, however it has certainly been an issue for me in the past.
Sometimes this is just referred to as "boot mode" and you must ensure it is not set to UEFI only.
Either way, this issue is solved.
-
I have yet to see a computer that doesn't have a fallback to non UEFI boot, as was mentioned there is likely a setting that is masking the option to enable normal non secure boot (or UEFI).
If you want to upload pics, throw them up on an external site such as Box or Google Drive, should only take a moment to complete.
What's your laptop make/model?
Are there any BIOS updates available?
-
I don't condone removing windows updated entirely but i will say how to if asked, and if you really need to, there is an option to defer updates which will allow your security updates to come through
Wasn't specifically at you, sorry if you took it that way!
Thanks for providing the path to your solution, his/her situation may differ but hopefully he/she can get it resolved and not resort to stopping updates for a long period.
Cheers.
-
It seems to reboot fine with SeaBIOS instead of OVMF. I'll have to try it a bit more to be certain, but it looks good so far.
Does anyone know if this would be a bug in OVMF or something I did wrong?
There have been reports of users with certain hardware having better results with OVMF or SeaBios, so just choose the one that works best for you if it makes a difference.
SeaBIOS will unfortunately kill any console VGA output if you happen to rely on this for your server.
Performance wise they should be identical once VGA arbitration is completed, and you are within the OS.
-
And is your laptop configred to boot from usb?
More than likely this since you said it works on your desktop.
When setting to boot from USB you may have to enable the legacy boot option (if there is one listed) and set the boot from USB to non UEFI (there are typically two options, the one you want may rely on legacy boot being set to enabled).
You can also likely try to hit F12 when the computer is on the boot screen and manually choosing the USB drive (more for testing than anything permanent).
-
Wouldn't the better solution be to fix/replace the hardware causing the issue?
There are certainly many combinations that work properly to alleviate this issue.
Something about proactively disabling updates to fix an issue that is not actually the root cause, leaving you exposed to possible vulnerabilties seems a bit backwards and ill advised.
I suppose for a short term fix it is reasonable, but certainly not long term.
-
Ha looks like im the first to have a prob!
Just updated and rebooted server but i cant now boot from the usb.
Just get
boot error
I had this happen with the previous B21 (haven't updated to this yet), a quick removal of the USB drive, insert into Windows, and running makebootable as Admin fixed it for me that time.
Try that and report back.
Yes can lower back to default.
Thanks.
-
I changed the Tunable (md_num_stripes) to 8192 to fix the deadlock issue. Should this be reverted back to default?
Wondering the same, if so, it'd likely be beneficial to add this instruction to the OP for others to follow.
-
Almost certainly related to GPU passthrough (it could be your USB controller also, but not as likely).
Can almost guarantee if you remove the GPU from the VM and test headless, you'll be able to reboot/shutdown a gazillion times without issue.
However this doesn't exactly fix the issue, but it does isolate it.
Unfortunately I don't have your specific GPU's, so I cannot provide much in the way of solutions for your specific setup.
You can attempt to pass the rom for the card, instructions here http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Management#Edit_XML_for_VM_to_supply_GPU_ROM_manually however I'm uncertain how much that is common practice anymore for "stubborn" cards.
Either way attempt that, and report back.
-
May I vote for beta release just fixing this nasty bug (e.g. 6.2.0-beta21a)?
After uncounted hard-reboots because of freezing unRAID machines several of my drives are gone. No cable problem, no adapter problem, they are just dead.
If a machine freezes it is no longer usable. Even a graceful IPMI down is not possible. I have to use the power-reset from IPMI. Don't know how many forced power-outages a typical drive survives ...
IMHO, it doesn't make sense to test Docker, KVM or whatever if a core functionality like copying one file over SMB can freeze a machine.
Just my 0.02.
Thanks for listening.
Stop Array. Go to Settings --> Disk Settings and change the num_stripes tunable from 1028 to 8192. Save. Start Array.
That should workaround the deadlock / web ui unresponsive issues during heavy IO for now.
The setting above has fixed lockups for me, have you performed this temporary work around and still have lockups?
-
Thanks bungee91 !
One of my priorities will be adding VM/Docker/Plugins management (start/stop/etc).
As for remote access, for the time being I'm letting VPN do the bulk of the work here.
But I will consider eventually having a plugin installed to help with some features.
Thanks, looking forward to the addition.
Took a quick test drive yesterday, and it worked well for my limited testing (I looked mainly, didn't start/stop array, etc...)
Two suggestions:
Running 6.2B21, with only 1 parity drive.
The 2nd parity is listed with Nan% or something like that for free space/size.
Maybe you can check for single parity and remove the entry entirely if not present?
2nd, even on my Nexus 6 (which is a pretty big phone) the buttons seem a little small to click on.
For instance the Gear icon in the top right took a couple of taps for me to click on it correctly so that it'd open.
Maybe the area for it's click could be bigger, or the icon resized to be a bit larger? IDK..
Either way both are very minor things/suggestions.
-
Thank you for making this app, I have just purchased this from the store.
I have not installed this yet, however did not see VM management (basics such as start/stop/force stop) as an option currently.
This would be my no.1 request for inclusion as you develop this further.
Edit: Thinking about this more, it would be nice to be able to control (if/as needed) the server from a remote location also.
In order to do this currently would involve allowing access to UnRAID from the outside world (which we all know would be a bad idea!), or using a VPN to tunnel into to be "local".
Would it be possible to control the server from the app through a plugin locally installed? Therefore exposing that plugins port, and securing the connection between the app and it for communication? This would then limit the risk, and only provide access to the apps functions just in case credentials were somehow stolen.
Just thinking out loud, can hear the wife calling me saying "The kitchen Tv is frozen, can you fix it?" which this would be perfect for!
-
As to your question of using the 2nd GPU for UnRAID, I believe this is more BIOS dependent as to having the option to set the primary GPU for booting.
If you do have this option, it is easy to set the primary display to the 2nd card, however not all BIOS's have this option.
If you wanted to pass all Nvidia cards (leaving none for the console/UnRAID), this may work for you http://lime-technology.com/forum/index.php?topic=43644.msg452464#msg452464 to work around the Nvidia issue mentioned above.
-
I just noticed my logs getting dumped full of these same messages but stopped when I shut down my Win10 VM.
The one thing I noticed yesterday evening is that the VM is not displaying video over the passed through GTX960 when it used to the day prior, the VM could see my receiver and did notice when I unplugged the HDMI cable.
My diagnostic file is too large to attach.
Hmm, so it's not just me.
Well I run 3 concurrent Windows 10 VM's, and haven't seen this issue until recently.
Since I have been going through hell with an RMA'd MB and video card (they seriously sent me 2 bad replacements; repeat RMA process), I cannot rule out that it is tied to changes with me swapping the board/video card to identical models.
I believe the dropping of my USB ports happens after this error repeats X amount of times (over and over), but I'll have to look further into diagnosing that.
Yeah... Memtest 5.01 is pretty old and buggy tbh
We use it at work, leaving it Single threaded works 100% and always catches errors (Leaving it on for 72hrs per server)
Multithreaded / SMP however... On our lowest end servers it works alright, but move up to Hexcore Xeons with DDR4 etc.... Memtest doesn't get along with that hardware haha
Single threaded mode should be more than ample at catching memory errors though
Interesting information, thanks!
Since you still test with 5.0.1 at work, is there a specific reason to not use the newest stable of V6.3.0?
I was never concerned with running it in multithread, however I had read recommendations to "really stress it" to use it that way.
I have no issues in default/single threaded in regards to it passing, so then I may really have an issue.. =(
My motherboard definitely has reports of some being more picky about ram than others (meaning the board itself from one identical model to testing with another).
My original one ran with the XMP profile set without any issues, this one (and the "borrowed one" in between) will not reliably operate with XMP enabled, so I have considered it a leave off option.
I'll do some more testing, however would certainly appreciate any insight/thoughts from the LT crew.
Totally get this is beta, but are others experiencing similar issues, is it an actual issue (or just me), etc...
As to my previous USB devices dropping, it happened again last night just prior to me saying "F*** it" and running Memtest.
The devices that drop are on the 4 ports that are from a secondary controller (built into the MB), all other chipset USB ports continue to work as expected.
I may just try exclusively using the chipset ones, and see if this is resolved.
-
Disregard my comments for now.
My RMA'd motherboard is a bit more finicky with my ram (exact same model as previously).
I can pass Memtest single threaded just fine (as I have tested) but on attempt for multi thread (F2) it never starts and just sits there, requiring a reset.
I was able to set the memory enhancement setting from "standard" to "stability" and the multi thread ran last night, however I woke up to UnRaid being booted (meaning it crashed and caused a reboot). Plan to bump up the voltage a tad, or relax the timings and hopefully all will pass as intended.
My experiences/issues are likely related to this at least somewhat.
Sorry to crap up the thread (as in likely not related to this release).
-
I'm seeing a lot of this recently in my syslog:
May 18 20:01:39 Server kernel: qemu-system-x86: page allocation failure: order:4, mode:0x260c0c0 May 18 20:01:39 Server kernel: CPU: 1 PID: 27063 Comm: qemu-system-x86 Not tainted 4.4.6-unRAID #1 May 18 20:01:39 Server kernel: Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./X99-SLI-CF, BIOS F21a 01/12/2016 May 18 20:01:39 Server kernel: 0000000000000000 ffff88089a03f8d0 ffffffff813688da 0000000000000001 May 18 20:01:39 Server kernel: 0000000000000004 ffff88089a03f968 ffffffff810bc9b0 0260c0c000000010 May 18 20:01:39 Server kernel: ffff880800000040 0000000400000040 0000000000000004 0000000000000004 May 18 20:01:39 Server kernel: Call Trace: May 18 20:01:39 Server kernel: [<ffffffff813688da>] dump_stack+0x61/0x7e May 18 20:01:39 Server kernel: [<ffffffff810bc9b0>] warn_alloc_failed+0x10f/0x127 May 18 20:01:39 Server kernel: [<ffffffff810bf9c7>] __alloc_pages_nodemask+0x870/0x8ca May 18 20:01:39 Server kernel: [<ffffffff810bfbcb>] alloc_kmem_pages_node+0x4b/0xb3 May 18 20:01:39 Server kernel: [<ffffffff810f40c2>] kmalloc_large_node+0x24/0x52 May 18 20:01:39 Server kernel: [<ffffffff810f6861>] __kmalloc_node+0x22/0x153 May 18 20:01:39 Server kernel: [<ffffffff81020994>] reserve_ds_buffers+0x18a/0x33f May 18 20:01:39 Server kernel: [<ffffffff8101b3e0>] x86_reserve_hardware+0x135/0x147 May 18 20:01:39 Server kernel: [<ffffffff8101b442>] x86_pmu_event_init+0x50/0x1c9 May 18 20:01:39 Server kernel: [<ffffffff810ade55>] perf_try_init_event+0x41/0x72 May 18 20:01:39 Server kernel: [<ffffffff810ae2a6>] perf_event_alloc+0x420/0x5b0 May 18 20:01:39 Server kernel: [<ffffffffa0098579>] ? kvm_perf_overflow+0x35/0x35 [kvm] May 18 20:01:39 Server kernel: [<ffffffff810b0210>] perf_event_create_kernel_counter+0x22/0x124 May 18 20:01:39 Server kernel: [<ffffffffa009868f>] pmc_reprogram_counter+0xbf/0x104 [kvm] May 18 20:01:39 Server kernel: [<ffffffffa00988e1>] reprogram_fixed_counter+0xc7/0xd8 [kvm] May 18 20:01:39 Server kernel: [<ffffffffa0098941>] reprogram_counter+0x4f/0x54 [kvm] May 18 20:01:39 Server kernel: [<ffffffffa00989b5>] kvm_pmu_handle_event+0x6f/0x8d [kvm] May 18 20:01:39 Server kernel: [<ffffffffa00816e1>] kvm_arch_vcpu_ioctl_run+0xad9/0x104e [kvm] May 18 20:01:39 Server kernel: [<ffffffffa007ba13>] ? kvm_arch_vcpu_load+0x133/0x16c [kvm] May 18 20:01:39 Server kernel: [<ffffffffa00730e9>] kvm_vcpu_ioctl+0x178/0x499 [kvm] May 18 20:01:39 Server kernel: [<ffffffff8149e416>] ? vfio_pci_read+0x11/0x16 May 18 20:01:39 Server kernel: [<ffffffff8149a03a>] ? vfio_device_fops_read+0x1f/0x29 May 18 20:01:39 Server kernel: [<ffffffff81109460>] ? __vfs_read+0x21/0xb1 May 18 20:01:39 Server kernel: [<ffffffff811175fd>] do_vfs_ioctl+0x3a3/0x416 May 18 20:01:39 Server kernel: [<ffffffff8111f5e7>] ? __fget+0x72/0x7e May 18 20:01:39 Server kernel: [<ffffffff811176ae>] SyS_ioctl+0x3e/0x5c May 18 20:01:39 Server kernel: [<ffffffff8161a0ae>] entry_SYSCALL_64_fastpath+0x12/0x6d May 18 20:01:39 Server kernel: Mem-Info: May 18 20:01:39 Server kernel: active_anon:1769977 inactive_anon:7535 isolated_anon:0 May 18 20:01:39 Server kernel: active_file:571686 inactive_file:390922 isolated_file:0 May 18 20:01:39 Server kernel: unevictable:4944875 dirty:1110 writeback:0 unstable:0 May 18 20:01:39 Server kernel: slab_reclaimable:266286 slab_unreclaimable:38176 May 18 20:01:39 Server kernel: mapped:27724 shmem:101866 pagetables:17989 bounce:0 May 18 20:01:39 Server kernel: free:44119 free_pcp:31 free_cma:0 May 18 20:01:39 Server kernel: Node 0 DMA free:15736kB min:8kB low:8kB high:12kB active_anon:128kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:32kB isolated(anon):0kB isolated(file):0kB present:15980kB managed:15896kB mlocked:32kB dirty:0kB writeback:0kB mapped:48kB shmem:160kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes May 18 20:01:39 Server kernel: lowmem_reserve[]: 0 821 32053 32053 May 18 20:01:39 Server kernel: Node 0 DMA32 free:125548kB min:584kB low:728kB high:876kB active_anon:95684kB inactive_anon:828kB active_file:1300kB inactive_file:1556kB unevictable:529080kB isolated(anon):0kB isolated(file):0kB present:851636kB managed:841968kB mlocked:529080kB dirty:4kB writeback:0kB mapped:2152kB shmem:8932kB slab_reclaimable:54024kB slab_unreclaimable:8800kB kernel_stack:1056kB pagetables:2964kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no May 18 20:01:39 Server kernel: lowmem_reserve[]: 0 0 31232 31232 May 18 20:01:39 Server kernel: Node 0 Normal free:35192kB min:22248kB low:27808kB high:33372kB active_anon:6984096kB inactive_anon:29312kB active_file:2285444kB inactive_file:1562132kB unevictable:19250388kB isolated(anon):0kB isolated(file):0kB present:32505856kB managed:31981696kB mlocked:19250388kB dirty:4436kB writeback:0kB mapped:108696kB shmem:398372kB slab_reclaimable:1011120kB slab_unreclaimable:143904kB kernel_stack:13152kB pagetables:68992kB unstable:0kB bounce:0kB free_pcp:120kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no May 18 20:01:39 Server kernel: lowmem_reserve[]: 0 0 0 0 May 18 20:01:39 Server kernel: Node 0 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 1*32kB (M) 3*64kB (UM) 1*128kB (U) 2*256kB (UM) 1*512kB (M) 2*1024kB (UM) 2*2048kB (UM) 2*4096kB (M) = 15736kB May 18 20:01:39 Server kernel: Node 0 DMA32: 369*4kB (UME) 573*8kB (UME) 410*16kB (UME) 284*32kB (UME) 198*64kB (UME) 130*128kB (UM) 81*256kB (UME) 53*512kB (UME) 18*1024kB (UME) 4*2048kB (M) 0*4096kB = 125516kB May 18 20:01:39 Server kernel: Node 0 Normal: 5707*4kB (UME) 1663*8kB (UM) 15*16kB (UM) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 36372kB May 18 20:01:39 Server kernel: 1064490 total pagecache pages May 18 20:01:39 Server kernel: 0 pages in swap cache May 18 20:01:39 Server kernel: Swap cache stats: add 0, delete 0, find 0/0 May 18 20:01:39 Server kernel: Free swap = 0kB May 18 20:01:39 Server kernel: Total swap = 0kB May 18 20:01:39 Server kernel: 8343368 pages RAM May 18 20:01:39 Server kernel: 0 pages HighMem/MovableOnly May 18 20:01:39 Server kernel: 133478 pages reserved
Time and time again (and again).
Given the timing of when this started, I had just starting playing with the Emby Beta docker, and noticed it was using up to ~4GB of memory, however the dashboard memory usage was never above 85% total. Maybe it started using previously cached ram, and this caused the error to start?
I did some searching and others had a similar issue (qemu-system-x86: page allocation failure: order:4), but it seemed to have been fixed in the more recent Linux kernel's (so shouldn't be the issue).
IDK, diagnostics attached.
-
I'm wondering how ram usage is for others of this docker?
I read some talk of this from this thread http://emby.media/community/index.php?/topic/32516-question-about-ram-usage/?hl=ram but nothing conclusive, or to be worried about either.
I'm testing with the current version of the beta server (currently version 3.0.5977.0), and no tasks are currently running from what I see on the server dashboard.
My library is scanned in, and LiveTv/recordings are setup. The resource monitor in CA shows anywhere from 2GB up to 4GB used by this Docker which seems a tad excessive, however is not causing any issues.
Since I don't typically leave this running as it is not my primary Media consumption choice currently (still on Kodi/TvHeadend) I'm concerned if this Docker will require more Ram than I'd expect.
I purchased the monthly Emby premiere to give this a good test prior to making a final decision, so any feedback on this is appreciated.
Also, the new Emby Theater for Windows is pretty sweet BTW!
-
OK, I disabled Turbo, Max CPU is 3600Mhz, with it enabled it's 3601Mhz,
CPU-Z in windows VM with turbo on shows 3.9Ghz + when running prime on all cores. With Turbo off it's max 3600Mhz,
So I guess the Dashboard wont report it?
Anyways seems to be resolved I guess.
Your findings agree with my previous results (w/i7-4790s), and seem normal. The dashboard never showed turbo frequencies, but it worked as expected.
However if you do not have issues with the CPU idling, I don't recommend enabling the intel_pstate=disable.
For some users it is the only way the cpu will throttle, leading to extra heat/power and sticking at max frequency (my i7-4790s did exactly this).
The pstate driver is better suited to handle the throttling of your CPU than other "generic" (if I can call it that) modes.
Since your end result still isn't reported exactly correct (taking into account the turbo frequency) I'd remove it.
----
On another note: I had most of my USB devices disappear yesterday, it was odd, only thing to fix this was a reboot of the server.
Removal/inserting did not register the device within the system devices page.
There were approximately 5 devices missing, however my UPS, keyboard, and a wireless receiver were still shown.
Supposedly 4 of my rear USB ports are from an ASMedia chip, the others are from the chipset.
I suppose it is possible (however I haven't looked) that these are plugged into the ASMedia, and it failed and reinitialized on reboot. Don't know, haven't looked specifically.
The ports on the AsMedia will not separate from the same bus as the others regardless of what I do (have tried all options).
I have a syslog, but no diagnostics from this particular occurrence.
I've always had some odd "USB rounding interval XX" errors which I cannot get rid of with too much time spent trying.
I had never seen this prior to yesterday, and it repeats a LOT
May 14 12:33:04 Server kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: May 14 12:33:04 Server kernel: 4-...: (0 ticks this GP) idle=4e8/0/0 softirq=50883399/50883399 fqs=0 May 14 12:33:04 Server kernel: (detected by 5, t=60002 jiffies, g=17816713, c=17816712, q=16930111) May 14 12:33:04 Server kernel: Task dump for CPU 4: May 14 12:33:04 Server kernel: swapper/4 R running task 0 0 1 0x00200000 May 14 12:33:04 Server kernel: ffffffff8150415f 0000000200000001 ffff8808bfc9f598 ffffffff81888a40 May 14 12:33:04 Server kernel: ffff88089c368000 ffff88089c364000 ffff88089c364000 ffff88089c367ed8 May 14 12:33:04 Server kernel: ffffffff81504231 ffff88089c367ef0 ffffffff81076247 0000000000000002 May 14 12:33:04 Server kernel: Call Trace: May 14 12:33:04 Server kernel: [<ffffffff8150415f>] ? cpuidle_enter_state+0x98/0x148 May 14 12:33:04 Server kernel: [<ffffffff81504231>] ? cpuidle_enter+0x12/0x14 May 14 12:33:04 Server kernel: [<ffffffff81076247>] ? call_cpuidle+0x4e/0x50 May 14 12:33:04 Server kernel: [<ffffffff810763cf>] ? cpu_startup_entry+0x186/0x1fd May 14 12:33:04 Server kernel: [<ffffffff81033cbf>] ? start_secondary+0xf4/0xf7 May 14 12:33:04 Server kernel: rcu_preempt kthread starved for 60002 jiffies! g17816713 c17816712 f0x0 s3 ->state=0x1 May 14 12:35:37 Server kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: May 14 12:35:37 Server kernel: 4-...: (0 ticks this GP) idle=374/0/0 softirq=50883399/50883399 fqs=0 May 14 12:35:37 Server kernel: (detected by 10, t=60002 jiffies, g=17816714, c=17816713, q=16926814) May 14 12:35:37 Server kernel: Task dump for CPU 4: May 14 12:35:37 Server kernel: swapper/4 R running task 0 0 1 0x00200000 May 14 12:35:37 Server kernel: ffffffff8150415f 0000000100000001 ffff8808bfc9f598 ffffffff81888a40 May 14 12:35:37 Server kernel: ffff88089c368000 ffff88089c364000 ffff88089c364000 ffff88089c367ed8 May 14 12:35:37 Server kernel: ffffffff81504231 ffff88089c367ef0 ffffffff81076247 0000000000000001
What the heck are "jiffies", cause my server is "starved" for them..
rcu_preempt kthread starved for 180005 jiffies!
Edit:
Actually it lists the issue here, however not sure of why this happened... I'm still blaming the need for more jiffies (backstory: it is a nickname my friend calls me, close to my name of Jeff, so yes I find that humorous).
May 15 16:37:06 Server kernel: usb usb3-port9: disabled by hub (EMI?), re-enabling... May 15 16:37:06 Server kernel: usb 3-9: USB disconnect, device number 4 May 15 16:37:06 Server kernel: usb 3-9.1: USB disconnect, device number 6 May 15 16:37:06 Server kernel: usb 3-9.1.3: USB disconnect, device number 8 May 15 16:37:06 Server kernel: usb 3-9.2: USB disconnect, device number 7 May 15 16:37:06 Server kernel: usb 3-9.3: USB disconnect, device number 9 May 15 16:37:07 Server kernel: usb usb3-port9: Cannot enable. Maybe the USB cable is bad? May 15 16:37:08 Server kernel: usb usb3-port9: Cannot enable. Maybe the USB cable is bad? May 15 16:37:09 Server kernel: usb usb3-port9: Cannot enable. Maybe the USB cable is bad? May 15 16:37:10 Server kernel: usb usb3-port9: Cannot enable. Maybe the USB cable is bad? May 15 16:37:10 Server kernel: usb usb3-port9: unable to enumerate USB device
-
Only if its on the parity driveOne more thing, not sure if you want it to be included in your checks.
I have this in my system log
kernel: ata9.00: HPA detected: current 1465147055, native 1465149168
which I'm well aware of, it won't easily get disabled on the drive (tried), and the BIOS setting which likely caused this doesn't apply to my current board (plus this drive is on the short list of being replaced).
However, for some users of old hardware (since this isn't "a thing" really anymore) it may be worth identifying and reporting, as the consequence(s) of HPA and a drive changing in size is a bad thing for UnRaid/parity protection.
I had thought that an array drive changing size was also bad for the calculated parity. Well either way, just thought I'd mention it.
-
I'll check it out and fix it on tonights updateI have a warning for a share which is array only that states there are files on the cache drive, however this is not the case.
Screenshot attached of the warning, and SSH ls of the contents of my cache drive.
Thanks!
-
One more thing, not sure if you want it to be included in your checks.
I have this in my system log
kernel: ata9.00: HPA detected: current 1465147055, native 1465149168
which I'm well aware of, it won't easily get disabled on the drive (tried), and the BIOS setting which likely caused this doesn't apply to my current board (plus this drive is on the short list of being replaced).
However, for some users of old hardware (since this isn't "a thing" really anymore) it may be worth identifying and reporting, as the consequence(s) of HPA and a drive changing in size is a bad thing for UnRaid/parity protection.
unRAID Server Release 6.2.0-beta23 Available
in Announcements
Posted
I thought this may have been solved, but just noticed it cropped up again in my syslog (certainly took longer to show up than previous beta (up 14 days now)).
This repeats multiple times with a couple of CPU assignments listed with the same error.
I assume this is an OOM condition, possibly from fragmentation or QEMU overhead.
I don't believe I'm assigning more than reasonable to the VM's, and leaving the host without enough for operations/Docker.
I also had this show up once, which was never there previously. The device is a PCIe root port, so not specifically an end device however has not occured again.
Diagnostics attached.
server-diagnostics-20160705-0734.zip