similar to: apc / ap9612th questions

Hi, We have a several AP9612TH environmental cards (they have 2 probe connectors) inserted into our APC UPS devices which monitor temperature and humidity. The apcsmart nut module knows how to query the ambient.temperature and ambient.humidity using the 't' and 'h' commands of the UPS (refer to apcsmart.h). The results of the 't' and 'h' commands are from probe 1.

Namely something like: ups.runtime - amount of seconds since powering up The reason is essentially "side effect" of this bug report: http://article.gmane.org/gmane.comp.monitoring.nut.user/7705 Where T denotes total time since ups' power up. On upses with AP9612TH it's used for dual temperature sensors (which top of apcsmart branch should gracefully support). Either way,

Hi, We have several APC Smart UPSes (serial port/apcsmart) with the APC Temp/Humidity sensor cards (AP9612TH). The sensor cards have 2 plugs for 2 separate sensors. So far, we have only used one of the sensors in conjunction with the apcsmart module from nut. This has been working great. Example output: [nut at nut]# upsc APC11 ambient.humidity: 037.2 ambient.humidity.alarm.maximum: NO,NO

Sorry for a bit longer delay than I anticipated, I was stuffed with the work. This is the next iteration of the patch adding some functionality to apcsmart driver, and relying on 'ignorelb' recently added. Follow up from previous thread: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02331.html Main differences is that V3 is split into many small patches, so the

On 10/13/2010 08:36 AM, syslinux-bot for Michal Soltys wrote: > Commit-ID: 9c8db7560e2dc83d1191bb2f90b4d4d0ae3d37d6 > Gitweb: http://syslinux.zytor.com/commit/9c8db7560e2dc83d1191bb2f90b4d4d0ae3d37d6 > Author: Michal Soltys <soltys at ziu.info> > AuthorDate: Wed, 13 Oct 2010 10:57:36 +0200 > Committer: Michal Soltys <soltys at ziu.info> > CommitDate: Wed, 13

Hi, For 6.xx: git://hasevolq.net/syslinux.git sys6 Michal Soltys (3): chain/partiter: call notsane_gpt_hdr() per header chain/partiter: add options to ignore GPT crc checks chain: year update in commments (trivial) Main addition here are separate options from 'strict' to ignore crc checks against gpt header and/or gpt partition list, so the user can force booting

>From the earlier patches - that simple fix for indexes not counting non-data partitions in gpt and mbr cases. Patches don't touch any other parts of the code at this stage - bigger stuff later for disklib as we agreed - but this is potentially useful right now. Michal Soltys (1): chain.c: fix public index value in mbr and gpt iterators

This is a bit updated set of chain.c32 changes that simplifies a few things (and in partiter part), fixes few minor issues and adds a few new features. Details are in the following commits, below is the summary and pull details at the end. Shao - any chance to peek over them ? Most of those are relatively simple changes and well tested, though of course something might have slipped my attention.

On Tue, Dec 2, 2014 at 8:27 PM, Michal Soltys <soltys at ziu.info> wrote: > Hi, > > For 6.xx: > > git://hasevolq.net/syslinux.git sys6 > > Michal Soltys (3): > chain/partiter: call notsane_gpt_hdr() per header > chain/partiter: add options to ignore GPT crc checks > chain: year update in commments (trivial) I'm not sure "Copyright

Configurations with multiple shared namespaces can trigger a bug where the first argument of strcmp() invocation is NULL. This patch adds an explicit check, analogously to how the second argument is sanitized. --- src/lib-storage/mail-storage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lib-storage/mail-storage.c b/src/lib-storage/mail-storage.c index

Inital tests with two apc units (2005 and pre-2000) seem to go well. See commit message for details. I'll add more detailed rationale after getting some sleep :) Michal Soltys (1): apcsmart: switch processing to ICANON + minor fixes drivers/apcsmart.c | 270 +++++++++++++++++++++++++++++++++++----------------- drivers/apcsmart.h | 127 ++++++++++++++++--------- 2 files changed, 267

I'm preparing a few simple patches that will cleanup few things regarding new chain - in particular the ones I mentioned in Januray during discussion with Shao (tone down overkill abstractions, etc.). One question on a formal side though - which license is preferred at the top of the source files ? Currently there're two present - either something bsd-ish (on parts derived from

Before I start any commits. In patch 2/18 - http://lists.alioth.debian.org/pipermail/nut-upsdev/2011-March/005299.html Two "custom" commands slipped in: ups.firmware.old and shutdown.return.grace. In 18/18 I tried to rename them and add remainig commands for "hackish" shutdown methods, to make them easily callable through e.g. upscmd (for example for testing). Is it

Hi, Are configurations (with separate formats per namespace) - such as ... namespace { type = shared list = children inbox = no separator = / subscriptions = no prefix = shared1/%%n/ location = maildir:/var/mail1/%%n/ } namespace { type = shared list = children inbox = no separator = / subscriptions = no prefix = shared2/%%n/ location =

This is 2nd version of the earlier patch featuring a few new features and fixes to the apcsmart driver, following the remarks in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02294.html Major changes from v1: - handle battery.charge and battery.runtime checks at main.c level - handle "immutable but writable" conflict gracefully at driver level -

Hi, I started updating smart driver with a few things I've been missing. While going through the source: - in upsdrv_shutdown(), there're loads of printfs - they kinda look like a leftover from older debug times. Shouldn't they be changed into upsdebugx() or upslogx() ?

After commit 036fa4e1a8aefeba3, shouldn't bsCodeLen be adjusted to reflect added fields at the end ? Basically: -#define bsCodeLen (offsetof(struct boot_sector, bsSignature) - \ +#define bsCodeLen (offsetof(struct boot_sector, bsMagic) - \

https://alioth.debian.org/tracker/?func=detail&atid=411544&aid=311678&group_id=30602 I wanted to do it somewhat more flexibly/elegantly, so this is what I've been thinking about (or rather sitting on mostly implemented piece, still needing some testing though): - any variable that may include multiple data, would be (during runtime) split into appropriate *.N.* sets; for

Hello, I was doing performance testing, validating zvol performance in particularly, and found that zvol write performance to be slow ~35-44MB/s at 1MB blocksize writes. I then tested the underlying zfs file system with the same test and got 121MB/s. Is there any way to fix this? I really would like to have compatible performance between the zfs filesystem and the zfs zvols. # first test is a

W dniu 22.07.2013 13:07, Matt Fleming pisze: > On Thu, 18 Jul, at 01:22:04PM, Adrian Irimia wrote: >> Hi, >> >> I have a bootable usb with syslinux 5.10 on wich the following code is working ok. >> LABEL - >> MENU LABEL GRUB LEGACY >> MENU INDENT 1 >> COM32 chain.c32 >> APPEND boot fs grub=/boot/grub-legacy/stage2