search for: l443

...y AtlantisLand UPS, the UPS don't want > to wake up after the whiteout and I don't have any idea why.. Some (very old) units are known to have problems with small values for ondelay (hence the default 3 minutes value): https://github.com/networkupstools/nut/blob/master/drivers/blazer.c#L443 Have you tried increasing the standard ondelay?

...lace .rept .. .endr with #defines. but to makes things more complicated apple's GAS does not support movsx instructions and thus the following line does not work: " movsx %%di, %%edi \n\t" [ more details at https://trac.xiph.org/browser/trunk/theora/lib/ x86_32/dsp_mmx.c#L443 ] if anyone has an idea how that could be replaced or written in a way that it works on OS X, please let me know. making asm optimization available for os x intel would be nice. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora_mactel.patch Type: ap...

In data giovedì 25 giugno 2015 14:50:03, Richard W.M. Jones ha scritto: > We had a chat about this on IRC, and I'm not very happy about any > patch that requires a special ./configure flag. I'm not sure where you see any special ./configure flag, other than what is already there (and not used much because makes things cumbersome). > We should find a way > to enable this

Hi all, I've problem with the management of my AtlantisLand UPS, the UPS don't want to wake up after the whiteout and I don't have any idea why.. This is the ups.conf: [ups] driver = blazer_usb subdriver = cypress vendorid = 0665 productid = 5161 port = auto desc = "AtlantisLand Host Power 851+" pollinterval = 10 offdelay = 60 this is the upsc result: battery.charge: 100

...e UPS don't want >> to wake up after the whiteout and I don't have any idea why.. > Some (very old) units are known to have problems with small values for > ondelay (hence the default 3 minutes value): > > https://github.com/networkupstools/nut/blob/master/drivers/blazer.c#L443 > > Have you tried increasing the standard ondelay?

...using from time to time, even if not often. > > Can you expand a bit more on the parts you consider racy? There are two objections: (1) That we currently have separate shutdown paths in the valgrind/non-valgrind case: https://github.com/libguestfs/libguestfs/blob/master/src/handle.c#L429-L443 https://github.com/libguestfs/libguestfs/blob/master/src/conn-socket.c#L346-L364 We shouldn't have two different paths that developers and non- developers use. (2) This actually causes bugs. The second one is the race. https://bugzilla.redhat.com/show_bug.cgi?id=1023630 https://bugzilla.red...

...cgi?id=1723367 [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367#c2 [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367#c3 [3] - https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_interface.c#L434 [4] - https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_interface.c#L443

Hi all, after a change of UPS (to Atlantis Host Power 851) I began to use the new driver blazer_usb and compared to old one (blazer used with serial connection) I noted more CPU use and errors in dmesg: [...] [256712.584370] usb 4-5: usbfs: USBDEVFS_CONTROL failed cmd blazer_usb rqt 33 rq 9 len 8 ret -110 [256789.640795] usb 4-5: usbfs: USBDEVFS_CONTROL failed cmd blazer_usb rqt 33 rq 9 len 8

On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: > On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote: >> Hi all, >> >> I'm aware that it is possible to plug pre-created macvtap devices to >> libvirt guests - tracked in RFE [0]. >> >> My interpretation of the wording in [1] and [2] is that it is also >> possible to plug