search for: 8qd

G'day y'all, Here's a tiny patch set for drivers/apcsmart.c and drivers/apcsmart.h. Adds APC SmartUPS 1250 ("8QD" case) + 940-0024C recognition to apcsmart. (Unpatched apcsmart.c v1.99.8 misidentifies the SmartUPS 1250 as a "dumb" UPS.) For NUT 2.0.5+. NUT 2.0.5: Patches apply successfully. Builds successfully. Works as expected under Ubuntu 7.04. NUT 2.2: Patches apply successfully (with...

...700 > +++ nut-2.2.2-r1/drivers/apcsmart.c 2008-12-06 03:24:36.000000000 -0700 > @@ -536,6 +536,7 @@ > /* found one, force the model information */ > if (!strcmp(buf, "6QD") || /* (APC600.) */ > !strcmp(buf, "8QD") || /* (SmartUPS 1250, > vintage 07/94.) */ > + !strcmp(buf, "7TD") || /* (SmartUPS 900, > vintage 11/94.) */ > !strcmp(buf, "6TI") || /* (APC600.) */ > !strcmp(buf, &q...

...have optimization turned up so high as on some other compilers. -- John Dallman ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

...gh as on some other compilers. > > -- > John Dallman > ----------------- > Siemens Industry Software Limited is a limited company registered in England and Wales. > Registered number: 3476850. > Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

In reply to the question about what would be the common use case: > What is the common use case? Making sure some funtion is always > optimized or making sure it never optimized? If the second one, I > wonder if marking it cold would be a good enough approximation. Although both cases would be nice and our users have expressed some interest in both, the critical one is the second case

...s. >> >> -- >> John Dallman >> ----------------- >> Siemens Industry Software Limited is a limited company registered in England and Wales. >> Registered number: 3476850. >> Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Develope...

...t could be done. Does anyone have a strong opinion about this? cheers, --renato ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130607/008c1457/attachment.html>

...=================== --- drivers/apcsmart.c (revision 1175) +++ drivers/apcsmart.c (working copy) @@ -536,7 +536,8 @@ /* found one, force the model information */ if (!strcmp(buf, "6QD") || /* (APC600.) */ !strcmp(buf, "8QD") || /* (SmartUPS 1250, vintage 07/94.) */ - !strcmp(buf, "6TI")) { /* (APC600.) */ + !strcmp(buf, "6TI") || /* (APC600.) */ + !strcmp(buf, "6QI")) { /* (APC600.) */...

Of course it's *possible*, in a fundamental sense. It's even pretty easy to get right in a compiler back end (in a conceptual sense). You have to touch a LOT of code, but all the changes are trivial. We did this at Tartan Labs back in the 90s. Done with only a bit of care, it makes debugging possible at any optimization level. The idea is to make the debug information reflect what the

...at it would be extremely helpful for debugging large programs. cheers, --renato ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130607/cc28921c/attachment.html>

On 7 June 2013 13:53, Dallman, John <john.dallman at siemens.com> wrote: > It needs to be possible to debug code at any optimisation level. > Yes, I agree. But after O1, sequential execution is a big impediment for optimizations, and keeping the debug information valid after so many transformations might pose a big penalty on the passes (time & memory). That was the whole idea

Folks, I'm trying to rationalize about optimization levels and maybe we should come up with a document like this: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html Though, I remember a discussion a few months ago, and some people recommended we had names, rather than numbers, to dissociate the idea that 3 is better than 2. Regardless, would be good to have some guidelines on what goes

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

This patch introduces a handful of new options, I mentioned earlier in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02088.html See the large commit message in the follow-up for the details and rationale. I realize it's a bit larger diff - so if it's required I can split it into few smaller ones. Michal Soltys (1): APC smart driver update and new features.

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 -

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking