February 21, 201511 yr unRAID OS Version: v6b13 & v6b14. Description: UPS communications lost after reboot. How to reproduce: Boot in Xen mode, enable pass through in syslinux.cfg, Xen VM set to auto start. xen-pciback.hide=(00:02.0)(00:03.0)(00:1b.0) This is passing through the Intel GPU, the hdmi video, and sound card on Asrock Z87 Extreme6. USB keyboard and mouse go off line and the server has to be power cycled. If Xen auto start is off, the UPS communications is normal. Xen VMs can be started manuallly and operation is normal Expected results: Communications to UPS not lost and USB devices stay on line. Actual results: UPS communications lost and USB devices go off line. Other information: This just started with the inclusion of apcups package. EDIT: The auto start VM is not the one with the GPU passed through.
February 21, 201511 yr unRAID OS Version: v6b13 & v6b14. Description: UPS communications lost after reboot. How to reproduce: Boot in Xen mode, enable pass through in syslinux.cfg, Xen VM set to auto start. xen-pciback.hide=(00:02.0)(00:03.0)(00:1b.0) This is passing through the Intel GPU, the hdmi video, and sound card on Asrock Z87 Extreme6. USB keyboard and mouse go off line and the server has to be power cycled. If Xen auto start is off, the UPS communications is normal. Xen VMs can be started manually and operation is normal Expected results: Communications to UPS not lost and USB devices stay on line. Actual results: UPS communications lost and USB devices go off line. Other information: This just started with the inclusion of apcups package. Did this not occur when apcupsd was instslled as a plugin??
February 21, 201511 yr No. Just showed up in b13. I don't get it. You mean beta14, right? Just want to make sure that beta13 + your plugin didn't have this same effect. Will test this out on Monday with beta12 + your plugin vs. beta14 and see if we can track it down. This is definitely odd behavior.
February 21, 201511 yr Author No. Just showed up in b13. I don't get it. You mean beta14, right? Just want to make sure that beta13 + your plugin didn't have this same effect. Will test this out on Monday with beta12 + your plugin vs. beta14 and see if we can track it down. This is definitely odd behavior. No. Beta 13 with the plugin and beta 14 with built in. The auto start VM can be any VM. It does not have to be the pass through VM. I don't understand how including the Apcupsd package could cause this interaction. It actually takes out my USB devices. I guess it affects the USB driver.
February 21, 201511 yr No. Just showed up in b13. I don't get it. You mean beta14, right? Just want to make sure that beta13 + your plugin didn't have this same effect. Will test this out on Monday with beta12 + your plugin vs. beta14 and see if we can track it down. This is definitely odd behavior. No. Beta 13 with the plugin and beta 14 with built in. The auto start VM can be any VM. It does not have to be the pass through VM. I don't understand how including the Apcupsd package could cause this interaction. It actually takes out my USB devices. I guess it affects the USB driver. Glad I clarified. This is odd behavior indeed. We'll figure it out.
February 21, 201511 yr so since it is now built in vice an add on, that makes me wonder if it is now a matter of timing / race condition perhaps. The "problem" may have always existed but not shown itself because the plugin was loading later than it is now. Just the first thing that comes to mind to consider looking into.
February 21, 201511 yr Author Yes, it may be a race condition. It's related to the apcupsd package. If I start unRAID with the Apcupsd daemon stopped and a xen VM auto started, it also fails if I then try to start the Apcupsd daemon. I'm concerned there is a gremlin here that may bite us in other areas.
February 21, 201511 yr Wait so I'm confused. I'm running a Xen VM that autostarted after upgrade. I then went into "UPS Settings" and started the daemon (it was reset to "no" after first reboot). And so far everything seems to be fine. I can comm with the UPS, and I can see my flash drive. I don't have a usb kb or mouse plugged in if that helps at all. I'm loath to reboot right now, but I'll do it to test if you like. EDIT: system log attached. this is from the first reboot after upgrade as described above. syslog.zip
February 21, 201511 yr Wait so I'm confused. I'm running a Xen VM that autostarted after upgrade. I then went into "UPS Settings" and started the daemon (it was reset to "no" after first reboot). And so far everything seems to be fine. I can comm with the UPS, and I can see my flash drive. I don't have a usb kb or mouse plugged in if that helps at all. I'm loath to reboot right now, but I'll do it to test if you like. I think dlandon's defect report is why autostart on VMs and the APCUPSd service are both on and the system first boots. Your scenario was the VMs booted and then you manually started the APCUPSd service. You could test for us and tell us if you have the same problem on reboot. Couldn't hurt to have one more person validate ;-)
February 21, 201511 yr Author Wait so I'm confused. I'm running a Xen VM that autostarted after upgrade. I then went into "UPS Settings" and started the daemon (it was reset to "no" after first reboot). And so far everything seems to be fine. I can comm with the UPS, and I can see my flash drive. I don't have a usb kb or mouse plugged in if that helps at all. I'm loath to reboot right now, but I'll do it to test if you like. I think dlandon's defect report is why autostart on VMs and the APCUPSd service are both on and the system first boots. Your scenario was the VMs booted and then you manually started the APCUPSd service. You could test for us and tell us if you have the same problem on reboot. Couldn't hurt to have one more person validate ;-) It happens when I am doing pci pass through with pci-back in the syslinux.cfg. It doesn't happen when I am not doing pci-back in syslinux.cfg. You should be good.
February 21, 201511 yr Wait so I'm confused. I'm running a Xen VM that autostarted after upgrade. I then went into "UPS Settings" and started the daemon (it was reset to "no" after first reboot). And so far everything seems to be fine. I can comm with the UPS, and I can see my flash drive. I don't have a usb kb or mouse plugged in if that helps at all. I'm loath to reboot right now, but I'll do it to test if you like. I think dlandon's defect report is why autostart on VMs and the APCUPSd service are both on and the system first boots. Your scenario was the VMs booted and then you manually started the APCUPSd service. You could test for us and tell us if you have the same problem on reboot. Couldn't hurt to have one more person validate ;-) It happens when I am doing pci pass through with pci-back in the syslinux.cfg. It doesn't happen when I am not doing pci-back in syslinux.cfg. You should be good. Another good piece of info. I didn't know that it only affected you when doing pass through.
February 21, 201511 yr Ahhh yes i thought that was a difference, but then dlandon's "EDIT" made me think he also tried it without pass-thru. But now I understand he means it is enabled, but the VM isn't using pass-thru. OK so I'll reboot for grins but I'm not expecting any trouble ... nor the spanish inquisition. aaaaaand reboot success. fwiw another syslog attached syslog.zip
February 21, 201511 yr Author Another good piece of info. I didn't know that it only affected you when doing pass through. Yes. I have an Intel iGPU I am passing through to a Windows 8.1 VM. It happens when I have any VM set to auto start. So here is the exact scnario: 1) - pci-back the Intel iGPU in syslinux.cfg. - Auto start a Debian VM - not the VM using the passed through GPU. - UPS Settings off. - Boot. Go to UPS Settings web page and start apcups daemon - link failure. 2) - pci-back the Intel iGPU in syslinux.cfg. - Auto start a Debian VM - not the VM using the passed through GPU. - UPS Settings on. - Boot, Go to UPS Settings web page - link failure. When the link failure occurs, I cannot stop and restart the apcupsd daemon and get communications established. My USB keyboard and mouse do not work. USB has stopped. I have to power off and re-start to get it back.
February 21, 201511 yr Author Jon, If you want more help with this, I can supply logs. I will have to wait for a time I can take the server down to create the problem. My problem is I don't know whether this is unraid, apcupsd, or Xen. You will have to let me know which log(s) would be needed. If it is not a fluke of my motherboard, you should be able to reproduce the problem easily by setting the GPU pci-back in syslinux.cfg and setting any VM to auto start. I don't think you will need anything special in a VM. Is there a chance that this is a Xen issue that could be solved with 4.5?
February 21, 201511 yr Jon, If you want more help with this, I can supply logs. I will have to wait for a time I can take the server down to create the problem. My problem is I don't know whether this is unraid, apcupsd, or Xen. You will have to let me know which log(s) would be needed. If it is not a fluke of my motherboard, you should be able to reproduce the problem easily by setting the GPU pci-back in syslinux.cfg and setting any VM to auto start. I don't think you will need anything special in a VM. Is there a chance that this is a Xen issue that could be solved with 4.5? I'm trying to be better about curbing my enthusiasm for taking educated guesses at the root cause. At this point it is just too early to tell where this is stemming from. The first thing I'll do when I'm back in the office on Monday is try to replicate. As techie as I am, I don't have a UPS at home ;-). Thankfully I don't live in the bermuda triangle like PeterB ;-)
February 26, 201511 yr Author I upgraded to b14b and I cannot get UPS communications even when I just pass through the iGPU. On b14 I could get the UPS communications to work if I did not auto start a VM. Now with all VMs set to not auto start and pci back set in the syslinux.cfg, I get no UPS communications. The USB keyboard and mouse connected to my server do not come on once unRAID is booted. It appears to me that the USB device drivers are not getting loaded to enable the USB ports, or are getting clobbered Syslog attached. EDIT: Apcupsd is currently started on the 'driver_loaded' event. Is that too soon? The plugin started apcupsd when the plugin was started. Would it be better to start apcupsd when the array is started? syslog.txt
February 26, 201511 yr I upgraded to b14b and I cannot get UPS communications even when I just pass through the iGPU. On b14 I could get the UPS communications to work if I did not auto start a VM. Now with all VMs set to not auto start and pci back set in the syslinux.cfg, I get no UPS communications. The USB keyboard and mouse connected to my server do not come on once unRAID is booted. It appears to me that the USB device drivers are not getting loaded to enable the USB ports, or are getting clobbered Syslog attached. EDIT: Apcupsd is currently started on the 'driver_loaded" event. Is that too soon? The plugin started apcupsd when the plugin was started. Would it be better to start apcupsd when the array is started. Ugh. Not good. Ok, let me chat with Tom / Eric on this tomorrow to get some insight.
February 26, 201511 yr Author Jonp, I'm convinced that the issue is that the apcups daemon is started too soon in the current scheme. It appears to be a race condition and by me adding the pci-back, there is a different timing to things getting started. I would recommend that the apcups daemon be started at the array_started event. There are those that would think that the apcups daemon not starting if the array doesn't start leaves them unprotected. This might be the case, but if the array is not started, the issues from a power outage are minimal when the array is not started. If you can move the start of the apcupsd daemon to the array_started event and give me a link to a test image, I will give it a go and let you know. You might not be able to reproduce the issue as easily as I can and I might save you some time that can be used for other things.
February 26, 201511 yr Jonp, There are those that would think that the apcups daemon not starting if the array doesn't start leaves them unprotected. This might be the case, but if the array is not started, the issues from a power outage are minimal when the array is not started. Worst case, give people an option when to load the daemon?
February 26, 201511 yr Author I don't think that is a good idea. The problem I am having takes out the USB ports and creates more problems than it is worth and will create a lot of support issues for LT.
February 26, 201511 yr There are those that would think that the apcups daemon not starting if the array doesn't start leaves them unprotected. This might be the case, but if the array is not started, the issues from a power outage are minimal when the array is not started. I would prefer that the system shuts down cleanly, whether the array is started, or not. However, unless one is in the habit of leaving the system running without starting the array, I would think that there is no problem. I have witnessed several occasions where the system has powered on after a powercut, only for the power to go off again within seconds. All that happens is that the array starts and then does a controlled shutdown again. Moving the apcupsd start would simply extend the time running on battery. Having said that, I would still be happier if there were another solution to this problem (which doesn't affect me)! It doesn't make sense that the kernel/pci-back should be sensitive to the sequence of starting the apcups daemon. The 'driver_loaded' event signifies that the md driver has finished loading - is it possible that other drivers (usb, for instance) have not finished loading at this time?
February 26, 201511 yr Author Once the array has started once, the apcups daemon will continue to run. Stopping the array will not stop the daemon. The only time this is an issue is if the array does not start on first boot. I think you are making this more of a problem than it is. How often do you reboot with the array stopped and walk away?
February 26, 201511 yr I think you are making this more of a problem than it is. I didn't think so! However, unless one is in the habit of leaving the system running without starting the array, I would think that there is no problem. I simply said that I would be happier if there were another solution. How often do you reboot with the array stopped and walk away? "Never!" "What, never?" "No, never!" "What, never?" "Well, hardly ever!" (With apologies to W.S. Gilbert.)
February 26, 201511 yr Author LT can probably insert the rc.apcupsd start into a more logical place to be sure it starts regardless of whether or not the array is started, and after the USB driver (Xen) is ready. On b14b, I got lost communications even when not doing pci-back and booting in Xen. Xen is taking over control of the hardware and I suspect that the apcups daemon is trying to attach a USB port and Xen is not ready for that.
Archived
This topic is now archived and is closed to further replies.