search for: resurrect

...- WRITE_DMA retrying (1 retry left) LBA=116030287 ad1: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=108911183 ad1: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=108378767 Since I could ping the system and after waiting a couple of hours in the hope the system would would resurrection by itself, I issued an flood-ping to this machine and voila, after getting the following lines: ... Limiting icmp ping response from 261 to 200 packets/sec Limiting icmp ping response from 283 to 200 packets/sec ... Anything went back to normality! This seems to me that we have an deadlock con...

I'm thinking I should make a commit robot (like the tip-bot for the Linux kernel) for klibc since development has been picking up again. I could revive the old klibc-cvs mailing list, or make a new one from scratch, or even direct all the commits to the main klibc mailing list. What would people's preference be, here? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work

Hi everybody I?d like to resurrect the discussion on a known issue with the openssh server, regarding signal delivery as described in rfc4254 This has been originally reported about ten years ago in this thread: https://bugzilla.mindrot.org/show_bug.cgi?id=1424 I am taking he liberty to copy a few people who contributed that threa...

I think the C backend also allow people performing source-to-source transform with LLVM (instead of Clang). ether On Tue, Aug 28, 2012 at 10:30 AM, Philipp Klaus Krause <pkk at spth.de> wrote: > Will this allow users to compile C++ (or some other language that LLVM > has a frontend for) to C, which then can be compiled using a C compiler > for a target architecture, for which only

On 8/27/2012 9:57 PM, Hongbin Zheng wrote: > I think the C backend also allow people performing source-to-source > transform with LLVM (instead of Clang). I do not believe that this would be the case nor that it should be a goal. Source-to-source transformation requires a lot of accurate information about the AST, and conversion to LLVM IR is way too lossy. Signedness, for example, is

Hi Roel, It's good to know that you're working on C backend. But IMO, the reason that C backend was removed in LLVM 3.1 is no one maintain the C backend. If you bring it back, would you like to take the responsibility for the maintaining work? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.)

On 27.08.2012 22:56, Roel Jordans wrote: > > Anyway, that brings to my final question: Which features are > critical/important/wanted/unwanted for a C back-end? > I'd like it to be easy to configure (e.g. to tell which size int is assumed to have). I'd prefer the resulting code to not rely on implementation-defined behaviour (e.g. not make any assumptions about the size of

Hi Everyone! I've been trying to rediscover the lost art of appliance-ification. SystemD is actually pretty amenable to masking tty1 and spawning a program instead of login which makes a config console a rather easy thing to do (mostly). Have that bit done, no problem. Happily spawning a rather locked down program. However, you seem to be limited in terms of color palette, creating a new

flac123 is back! Version 0.0.3 is now available at http://flac-tools.sourceforge.net . flac123 now supports FLAC 1.1.0, and its remote mode mimics mpg123's. Please test it for bugs and report them to the flac-tools sourceforge forum. _________________________________________________________________ Share holiday photos without swamping your Inbox. Get MSN Extra Storage now!

Code changes and cleanup in the paravirt-ops queue caused the original fix for this in 2.6.21 to create conflicts. The easiest thing to do was back it out before applying the queue. In that case, this fix brings it back with the newly right properly tidied up paravirt-ops code. Wheee! Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r ecb571084874 arch/i386/kernel/vmi.c ---

I have a small file of the type that S-PLUS produced and stored in .Data/ directories back in the days before we used R. I'm fairly sure it would become a dataframe if read into Ver 3.4 of that august predecessor to what we use now. (It was Solaris in case that makes any difference.) AFAIK, the format that S-PLUS uses changed after that, so a current version would find it unreadable. If

Code changes and cleanup in the paravirt-ops queue caused the original fix for this in 2.6.21 to create conflicts. The easiest thing to do was back it out before applying the queue. In that case, this fix brings it back with the newly right properly tidied up paravirt-ops code. Wheee! Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r ecb571084874 arch/i386/kernel/vmi.c ---

On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote: > On 28.08.2012 14:08, Joshua Cranmer wrote: >> On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >>> I think the C backend also allow people performing source-to-source >>> transform with LLVM (instead of Clang). >> >> I do not believe that this would be the case nor that it should

On 28.08.2012 14:47, Cameron Zwarich wrote: > On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote: > >> On 28.08.2012 14:08, Joshua Cranmer wrote: >>> On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >>>> I think the C backend also allow people performing source-to-source >>>> transform with LLVM (instead of Clang). >>>

On 28/08/12 04:30, Philipp Klaus Krause wrote: > Will this allow users to compile C++ (or some other language that LLVM > has a frontend for) to C, which then can be compiled using a C compiler > for a target architecture, for which only a C compiler exists? > Which use-cases do you have in mind for this backend? > Possibly yes, compiling C++ to C would require support for things

Will this allow users to compile C++ (or some other language that LLVM has a frontend for) to C, which then can be compiled using a C compiler for a target architecture, for which only a C compiler exists? Which use-cases do you have in mind for this backend? Philipp

On 28.08.2012 14:08, Joshua Cranmer wrote: > On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >> I think the C backend also allow people performing source-to-source >> transform with LLVM (instead of Clang). > > I do not believe that this would be the case nor that it should be a > goal. Source-to-source transformation requires a lot of accurate > information about the AST,

...or speed was "too fast" that it is failing to find its mounts OR that the disk reported errors. It is on a dmraid (I know, please don't flame me). There is some critical information on the drives that did NOT backup. I need a list of tools and ideas to have a checklist to try and resurrect this machine. Of course I will go with - Live CD - CentOS 5.5 install. - Hard drives. I would appreciate any procedural methods to go about this and try to resurrect this machine.

...in bug database on this topic. > Now after 3 years, what's the status of this issue? Are there still any > problems in the pass if i compile and run it? > > > I do not believe that the status has changed. I believe the -dsa-aa pass > in DSA is still removed and has not been resurrected (at least not with a > patch that applied cleanly to the release_32 branch). > > If someone wants to resurrect -dsa-aa with a patch that cleanly applies to > the release_32 branch or the trunk branch, I'll review it and apply it. > > Regards, > > John Criswell > &gt...

...p://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > There is even qemu support for microblaze. I think it's excessive to remove a port so easily. Once you announce that you want to remove it, you should wait at least a year. It may have to wait for funding to be resurrected. gcc had ports that nobody used for 10 years before they finally deleted them. Reed