July 27, 201015 yr I'm getting this message written to the logfile every ten seconds: Tower kernel: generic-usb 0003:051D:0002.0001: control queue full What does it mean and what should I do about it? This is probably the port (No. 3?) which connects to my APC UPS.
July 27, 201015 yr Author Yep. that's certainly stopped it! Jul 28 01:23:45 Tower kernel: generic-usb 0003:051D:0002.0001: control queue full Jul 28 01:24:25 Tower last message repeated 4 times Jul 28 01:25:35 Tower last message repeated 7 times Jul 28 01:26:45 Tower last message repeated 7 times Jul 28 01:27:55 Tower last message repeated 7 times Jul 28 01:29:05 Tower last message repeated 7 times Jul 28 01:29:55 Tower last message repeated 5 times Jul 28 01:30:01 Tower kernel: usb 1-1.1: USB disconnect, address 3 Jul 28 01:31:06 Tower apcupsd[1640]: Communications with UPS lost. ... and the error doesn't reappear on reconnecting the UPS: Jul 28 01:34:16 Tower kernel: usb 1-1.1: new low speed USB device using ehci_hcd and address 5 Jul 28 01:34:16 Tower kernel: usb 1-1.1: configuration #1 chosen from 1 choice Jul 28 01:34:17 Tower kernel: generic-usb 0003:051D:0002.0002: hiddev96,hidraw0: USB HID v1.10 Device [American Power Conversion Back-UPS CS 650 FW:817.v4.I USB FW:v4] on usb-0000:00:1a.0-1.1/input0 Jul 28 01:34:20 Tower apcupsd[1640]: Communications with UPS restored. Thanks, Bubba. Now, this probably started at about the time I was experimenting with how to wake the server from S3 suspend to ram state, when the UPS reports a power fail, but I'm still not clear why the system got itself into this error state.. Anyway, I've already got wol working with a magic packet but, in order to perform a powerdown when the UPS loses mains power, I believe that I will need to get the server to wake on usb. Any thoughts on this ... perhaps I should start a new topic?
July 27, 201015 yr Yep. that's certainly stopped it! Jul 28 01:23:45 Tower kernel: generic-usb 0003:051D:0002.0001: control queue full Jul 28 01:24:25 Tower last message repeated 4 times Jul 28 01:25:35 Tower last message repeated 7 times Jul 28 01:26:45 Tower last message repeated 7 times Jul 28 01:27:55 Tower last message repeated 7 times Jul 28 01:29:05 Tower last message repeated 7 times Jul 28 01:29:55 Tower last message repeated 5 times Jul 28 01:30:01 Tower kernel: usb 1-1.1: USB disconnect, address 3 Jul 28 01:31:06 Tower apcupsd[1640]: Communications with UPS lost. ... and the error doesn't reappear on reconnecting the UPS: Jul 28 01:34:16 Tower kernel: usb 1-1.1: new low speed USB device using ehci_hcd and address 5 Jul 28 01:34:16 Tower kernel: usb 1-1.1: configuration #1 chosen from 1 choice Jul 28 01:34:17 Tower kernel: generic-usb 0003:051D:0002.0002: hiddev96,hidraw0: USB HID v1.10 Device [American Power Conversion Back-UPS CS 650 FW:817.v4.I USB FW:v4] on usb-0000:00:1a.0-1.1/input0 Jul 28 01:34:20 Tower apcupsd[1640]: Communications with UPS restored. Thanks, Bubba. Now, this probably started at about the time I was experimenting with how to wake the server from S3 suspend to ram state, when the UPS reports a power fail, but I'm still not clear why the system got itself into this error state.. Anyway, I've already got wol working with a magic packet but, in order to perform a powerdown when the UPS loses mains power, I believe that I will need to get the server to wake on usb. Any thoughts on this ... perhaps I should start a new topic? Actually, that is not how it is usually done. I have my server BIOS set to automatically power on upon power restore. I have my "apcupsd" package, as installed by unMENU, set to power off the UPS at the end of the powerdown sequence. If I lose power for an extended time the apcuupsd daemon invokes /sbin/powerdown. As the very last step, the UPS is sent a "killpower" command. That shuts down the UPS after a short delay so it does not deplete its batteries. When power returns, the server automatically powers itself back on (because of the BIOS setting) and the server is available once more. It has absolutely nothing to do with s3 sleep, and in fact, won't work if it is sleeping, as apcupsd is not listening. (perhaps some wake-on-usb-activity might get it to wake, never tried)
July 27, 201015 yr Author Anyway, I've already got wol working with a magic packet but, in order to perform a powerdown when the UPS loses mains power, I believe that I will need to get the server to wake on usb. Any thoughts on this ... perhaps I should start a new topic? Actually, that is not how it is usually done. I have my server BIOS set to automatically power on upon power restore. I have my "apcupsd" package, as installed by unMENU, set to power off the UPS at the end of the powerdown sequence. If I lose power for an extended time the apcuupsd daemon invokes /sbin/powerdown. As the very last step, the UPS is sent a "killpower" command. That shuts down the UPS after a short delay so it does not deplete its batteries. When power returns, the server automatically powers itself back on (because of the BIOS setting) and the server is available once more. Yes, I already have all of this working exactly as you describe. It has absolutely nothing to do with s3 sleep, and in fact, won't work if it is sleeping, as apcupsd is not listening. (perhaps some wake-on-usb-activity might get it to wake, never tried) This is what I'm attempting to achieve. If the machine is in S3 state when a power failure occurs, then the UPS will simply run until its battery runs down (of course, it may take quite a long time to do this if the machine is sleeping), at which point the unRAID server will lose its saved state. On restoration of power, the server will boot from cold and run a parity check. Ah ... perhaps if the commands <mover> and <sync> are invoked prior to going to sleep, the parity check will not be invoked? If so, then the only problem would be that the UPS would run until its battery is depleted ... unless there is some way to instruct the UPS to <killpower> at some time after a powerfail, before the server goes to sleep, and without further involvement of the server.
July 27, 201015 yr Anyway, I've already got wol working with a magic packet but, in order to perform a powerdown when the UPS loses mains power, I believe that I will need to get the server to wake on usb. Any thoughts on this ... perhaps I should start a new topic? Actually, that is not how it is usually done. I have my server BIOS set to automatically power on upon power restore. I have my "apcupsd" package, as installed by unMENU, set to power off the UPS at the end of the powerdown sequence. If I lose power for an extended time the apcuupsd daemon invokes /sbin/powerdown. As the very last step, the UPS is sent a "killpower" command. That shuts down the UPS after a short delay so it does not deplete its batteries. When power returns, the server automatically powers itself back on (because of the BIOS setting) and the server is available once more. Yes, I already have all of this working exactly as you describe. I understand. That is a good starting point. It has absolutely nothing to do with s3 sleep, and in fact, won't work if it is sleeping, as apcupsd is not listening. (perhaps some wake-on-usb-activity might get it to wake, never tried) This is what I'm attempting to achieve. If the machine is in S3 state when a power failure occurs, then the UPS will simply run until its battery runs down (of course, it may take quite a long time to do this if the machine is sleeping), at which point the unRAID server will lose its saved state. On restoration of power, the server will boot from cold and run a parity check. Ah ... perhaps if the commands <mover> and <sync> are invoked prior to going to sleep, the parity check will not be invoked? If so, then the only problem would be that the UPS would run until its battery is depleted ... unless there is some way to instruct the UPS to <killpower> at some time after a powerfail, before the server goes to sleep, and without further involvement of the server. Running "mover" and sync will not help. (although a sync won't hurt) If the UPS depletes its batteries, then the RAM you saved the S3 state to, forgets. A possible solution... (of many) Enable wake-on USB activity in your BIOS. It might wake the server when the UPS attempts to tell it of a power failure. If that does not work, consider using the wake-on-ring signal monitored by some BIOS. Typically this is supplied to a pin on the serial port. If you can engineer a proper signal voltage/ground that is needed to occur when power fails, then it would simulate the ringing of the phone and wake the server. Once awakened, it might then be able to listen to subsequent messages from the UPS for when its batteries are nearing the limits you set. Another possibility... use a SERIAL cable to connect your UPS instead of a USB cable. Many UPS use the ring-indicator pin of the cable to indicate a power loss has occurred. This in combination with the wake-on-ring BIOS feature enabled might work to wake the server. Easiest solution... buy a HUGE UPS, one that will last through an extended outage. This one will probably power your server in s3 mode for a few days, and since it is an APC brand might work with the apcupsd software too: http://cgi.ebay.com/SYPX80-APC-80kva-SY80K80F-Symmetra-PX-3p-UPS-NewBatts-/130344680233?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item1e5925fb29 Joe L.
July 27, 201015 yr Easiest solution... buy a HUGE UPS, one that will last through an extended outage. This one will probably power your server in s3 mode for a few days, and since it is an APC brand might work with the apcupsd software too: http://cgi.ebay.com/SYPX80-APC-80kva-SY80K80F-Symmetra-PX-3p-UPS-NewBatts-/130344680233?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item1e5925fb29 Joe L. Now that's a UPS. I worked in one computer room that had a dedicated UPS room with batteries. there was a whole room full of cabinets like that. When you walked in there you could feel the electricity in the air. Sometimes the hair on my arms would stand up.
July 27, 201015 yr Easiest solution... buy a HUGE UPS, one that will last through an extended outage. This one will probably power your server in s3 mode for a few days, and since it is an APC brand might work with the apcupsd software too: http://cgi.ebay.com/SYPX80-APC-80kva-SY80K80F-Symmetra-PX-3p-UPS-NewBatts-/130344680233?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item1e5925fb29 Joe L. Now that's a UPS. I worked in one computer room that had a dedicated UPS room with batteries. there was a whole room full of cabinets like that. When you walked in there you could feel the electricity in the air. Sometimes the hair on my arms would stand up. I worked for a Bell-system building that had 4 750KW Diesel turbines on the floor just below the roof. ( Picture small jet engines, turning at 30,000RPM ) Almost 1/2 of the floor below that was a dedicated UPS with huge numbers of batteries. Makes the one I pictured look tiny. The goal was to not have the telephone system stop working in a power failure. It almost worked... First time they were used in an actual extended power outage they learned the pump that pumped the fuel from the large in-ground tank to a small 500 gallon holding tank on the top floor was not on the UPS. Once the first 500 gallons of fuel were used, it got a lot quieter around the turbines. Needless to say it was long night while we primed them for a re-start. (I was not one of those who had to carry 5 gallon cans of fuel up 18 flights of stairs. I was one of the people running new power wires from the panel in the basement that fed the pump, up the stairwell to a computer room on the first floor where we could tap off some power to run it.) Joe L.
July 28, 201015 yr Author Ah ... perhaps if the commands <mover> and <sync> are invoked prior to going to sleep, the parity check will not be invoked? If so, then the only problem would be that the UPS would run until its battery is depleted ... unless there is some way to instruct the UPS to <killpower> at some time after a powerfail, before the server goes to sleep, and without further involvement of the server. Running "mover" and sync will not help. (although a sync won't hurt) If the UPS depletes its batteries, then the RAM you saved the S3 state to, forgets. Yes, of course the contents of the RAM would be lost. The primary reason for protecting the unRAID server with a UPS is to prevent data corruption/loss, and to eliminate the need for a lengthy parity check when the power is restored. My point was that, perhaps, both of these problems are eliminated if the server has already invoked 'mover' and 'sync' before it goes down. If so, this would be a better option than waking the server up simply for it to power down. A possible solution... (of many) Enable wake-on USB activity in your BIOS. It might wake the server when the UPS attempts to tell it of a power failure. Yes, I'll go back and recheck that wake-on USB is enabled in the BIOS. If that does not work, consider using the wake-on-ring signal monitored by some BIOS. Typically this is supplied to a pin on the serial port. If you can engineer a proper signal voltage/ground that is needed to occur when power fails, then it would simulate the ringing of the phone and wake the server. Once awakened, it might then be able to listen to subsequent messages from the UPS for when its batteries are nearing the limits you set. Another possibility... use a SERIAL cable to connect your UPS instead of a USB cable. Many UPS use the ring-indicator pin of the cable to indicate a power loss has occurred. This in combination with the wake-on-ring BIOS feature enabled might work to wake the server. Okay, both might be possible ... but it would be nice to be able to rely on the USB ... I have 12 USB ports, while the legacy ports, such as serial, only exist as headers on the mobo. Easiest solution... buy a HUGE UPS, one that will last through an extended outage. This one will probably power your server in s3 mode for a few days, and since it is an APC brand might work with the apcupsd software too: http://cgi.ebay.com/SYPX80-APC-80kva-SY80K80F-Symmetra-PX-3p-UPS-NewBatts-/130344680233?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item1e5925fb29 Well, that is an option! I wonder whether the $500 would cover shipping to Philippines? Also, since it is 3-phase, I could run three separate circuits from it!
July 28, 201015 yr both of these problems are eliminated if the server has already invoked 'mover' and 'sync' before it goes down. If so, this would be a better option than waking the server up simply for it to power down. Only way to avoid a parity check would be to stop the array before going to sleep/power down. Simply performing a "sync" will not do it. as far as using the serial port all you really need to do is wire the RI pin. You can leave the UPS connected by USB. A small relay, powered by AC, with normally closed contacts connected to the RI and ground would close the contacts upon power failure. that would wake the server.
Archived
This topic is now archived and is closed to further replies.