search for: _cs

...(1,5)for (i in nl) { assign(paste0("df_",nl[i]),data.frame(x=seq(1:10),y=rnorm(10)))} ls()[grep("df_",ls())] nls<-ls()[grep("df_",ls())]for (df in nls) { print(df) for (var in names(get(df))) { print(var) assign(paste0(df,"$",paste0(var,"_cs")),cumsum(get(df)[[var]])) }} ls()[grep("df_",ls())] The code above *almost* works, except that it creates a whole bunch of objects of the form df_1$x_cs,df_1$yx_cs ..... What I want is 5 dataframes, with the $ elements enclosed, as usual. Any help or guidance would be appreciate...

...numa.h | 5 --- xen/include/asm-arm/platform.h | 2 + 10 files changed, 88 insertions(+), 58 deletions(-) -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg at m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u3 Debian 8.2 installed on a supermicro H8SGL Board, AMD 6128 with 4x4GB ECC RAM. When booting the plain kernel (stock Jessie 3.16 or backport 4.1 or 4.3), both memory controllers (mc0 and mc1) appear under /sys/devices/system/edac/mc with two csrow* each as expected. Same happens, when booted with Xen 4.1.4-3+deb7u1. When booted with Xen

...kly to get noticed as urgent. Now to continuing the work on figuring out the consequences from upgrading hardware a bit too early... -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg at m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

...elif [ -z "$type" ]; then error "Can't read hypervisor type from sysfs!" else -- 2.20.1 -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg at m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

...2 (POLLED) I have not tried force-enabling ECC checking. Since I place high value on my data, I rate this as a rather important bug. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | EHeM+sigmsg at m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

...I think this should be a fairly high priority for Xen since ECC memory is a feature very common on systems running with a hypervisor. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | EHeM+sigmsg at m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Elliott Mitchell writes ("[PATCH 12/12] Partially revert "Cross-compilation fixes.""): > This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7. Wow, that is an upsteam commit from 2005. However, I would like some kind of explanation. Is it in fact now false that | # These don't cross-compile ? Should this patch go upstream ? Ian. -- Ian Jackson

...kernel bug. So far no crashes/confirmed data loss have occured, but sweeping the mirror does turn up small numbers of inconsistencies. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg at m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Package: xen-utils-common Version: 3.0.3-0-2 Severity: wishlist The "xendomains" init script will start domains according to the order of config files found in /etc/xen/auto/*. I use this so that, in the event of a hard reboot, the more important domains will start first. Some of these contain essential services like DNS resolvers, slapd and so on, and since starting xen domains

Package: src:xen Version: 4.11.1-1 Currently, these are rdepends: -$ apt-cache rdepends libxenmisc4.11 libxenmisc4.11 Reverse Depends: libxen-dev xen-utils-4.11 collectd qemu-system-x86 libvirt-daemon collectd-core It's on the wishlist to start doing buster-backports for Xen. If the user has a cluster of servers and can make use of live migrate, then this allows the user to

Package: src:xen Version: 4.14.1+11-gb0b734a8b3-1 Severity: critical Justification: causes serious data loss X-Debbugs-Cc: debianbts at virtualzone.hu Dear Maintainer, after a clean install of bullseye/testing the xen dmesg shows the following message: (XEN) AMD-Vi: IO_PAGE_FAULT: 0000:01:00.1 d0 addr fffffffdf8000000 flags 0x8 I this is the sata device: 01:00.1 SATA controller: Advanced Micro

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