Bproc

bproc@lists.fedorahosted.org

7 discussions

Status of bproc port to RHEL 6.2
by John Hawkes 02 Apr '12

02 Apr '12

Hi all, An FYI ... I've been grinding along with the bproc port to RHEL 6.2, debugging -- and making fixes -- and I've made significant progress in the last couple of days. * I've got the bproc_move() intrinsic working [apparently] reliably. That's the underlying bproc functionality that moves a process image from one node to another, and it validates a bunch of the changes needed for bproc in RHEL 6.2, including assembler code, changes to the interface to the kernel's vfs (virtual file system) layer, changes to the kernel's syscall interface, and a rewrite of bproc's /bpfs filesystem. * The bpsh command, which uses bproc_move() (and other bproc functionality), now partially works: I can bpsh a simple program that does both a printf() and a syslog() of its argument values. The syslog() works, but the printf() doesn't -- and the printf() is a crucial piece. I'm in the midst of trying to figure out why printf() doesn't work. However, a simple program that does a bproc_move() to a compute node and executes a printf() *does* work. * As more and more of the bpsh functionality begins to work correctly, that gets me farther and farther into the node-booting scripts ("node_up" and "setup_fs"), which encounters various incompatibilities between RHEL 4&5 and RHEL 6. I'm fixing or working around those incompatibilities. * Though because a bpsh'ed program's stdout isn't working, that breaks many of the uses of bpsh in the 'node_up' and 'setup_fs' scripts. So it's real progress. And as more bproc_move() and bpsh functionality comes alive, the easier the debugging of the remaining problems. -- John Hawkes

2 7

Fwd: Re: Scyld filecache, /rootfs, etc.
by Adam Young 09 Feb '12

09 Feb '12

This change is probably relevant to how BProc does the system call. -------- Original Message -------- Subject: Re: Scyld filecache, /rootfs, etc. Date: Mon, 23 Jan 2012 23:01:49 -0500 From: Adam Young <ayoung(a)redhat.com> To: John Hawkes <jhawkes(a)penguincomputing.com> On 01/23/2012 03:19 PM, John Hawkes wrote: > On Mon, Jan 23, 2012 at 11:59 AM, John Hawkes > <jhawkes(a)penguincomputing.com> wrote: >>> If they are loaded before the migrate, they get there via task_packer. If >>> not, they need to be in place. I forget the order that things happen >>> ...been too long. You can use an nfs root to preposition the libraries. >> Ohhh right right right. It's "bpsh -M" to do an exec-move, vs. the >> default move-exec. >> I tried that, and I see the same quick-exit. > Ummm no, "bpsh -M" is the default. It may do the exec locally on the > master, but that doesn't run the loader to load the libraries. That > is done on the compute node. > > When I do "bpsh -m" -- MOVE-EXEC -- then it doesn't try to load the > libraries, but it does fail quickly, and this time with an exit code > of 11 (0xb), after it exits to user space. I'm thinking maybe I have > the bproc_kernel_thread and bproc_child_rip wrong. I already had to > fix the bproc_kernel_thread for RHEL6. Maybe I did that wrong, or > maybe I need to make changes to bproc_child_rip, too. One diff > between the RHEL5 and RHEL6 kernel_thread is the addition of an extra > push: > > /usr/src/debug////////kernel-2.6.32-220.2.1.el6/linux-2.6.32-220.2.1.el6.620a0001.x86_64/arch/x86/kernel/entry_64.S:1172 > ffffffff8100c060<kernel_thread> 31 c0 xor %eax,%eax > ffffffff8100c062<kernel_thread+0x2> 6a 18 pushq > $0x18<<<<<<<<<<<<<<<<<<<< > ffffffff8100c064<kernel_thread+0x4> 50 push %rax > ffffffff8100c065<kernel_thread+0x5> 68 00 02 00 00 pushq $0x200 > ffffffff8100c06a<kernel_thread+0xa> 6a 10 pushq $0x10 > ffffffff8100c06c<kernel_thread+0xc> 68 40 c1 00 81 pushq > $0xffffffff8100c140 > ffffffff8100c071<kernel_thread+0x11> 50 push %rax > > > John I don't have the RHEL5 code handy. I am not sure exactly which line is the "extra push" The comment is /* push in order ss, rsp, eflags, cs, rip */ Line 1172 is the macro FAKE_STACK_FRAME $child_rip From the git blame of Linus' tree: 1cf8343f arch/x86/kernel/entry_64.S (Seiichi Ikarashi 2011-12-06 17:58:14 +0900 225) pushq_cfi $(X86_EFLAGS_IF|X86_EFLAGS_BIT1) /* eflags - interrupts on */ x86: Fix rflags in FAKE_STACK_FRAME The x86_64 kernel pushes the fake kernel stack in arch/x86/kernel/entry_64.S:FAKE_STACK_FRAME, and rflags register in it does not conform to the specification. Although Intel's manual[1] says bit 1 of it shall be set to 1, this bit is cleared to 0 on pushing the fake stack. [1] Intel(R) 64 and IA-32 Architectures Software Developer's Manual Vol.1 3-21 Figure 3-8. EFLAGS Register If it is not on purpose, it is better to be fixed, because it can lead some tools misunderstanding the stack frame. For example, "crash" utility[2] actually detects it and warns you like below: But I suspect that was just the change: - pushq_cfi $X86_EFLAGS_IF /* eflags - interrupts on */ + pushq_cfi $(X86_EFLAGS_IF|X86_EFLAGS_BIT1) /* eflags - interrupts on */ Before that it was: df5d1874 arch/x86/kernel/entry_64.S (Jan Beulich 2010-09-02 14:07:16 +0100 224) pushq_cfi $X86_EFLAGS_IF /* eflags - interrupts on */ x86: Use {push,pop}{l,q}_cfi in more places ... plus additionally introduce {push,pop}f{l,q}_cfi. All in the hope that the code becomes better readable this way (it gets quite a bit smaller in any case). which I guess is where the _cfi comes from. Which push didn't exist in the RHEL 5 Kernel?

1 0

Fwd: Re: kernel.spec and scyld patch - for 2.6.32-220.4.1
by Adam Young 09 Feb '12

09 Feb '12

Old message that should have been on the mailing list -------- Original Message -------- Subject: Re: kernel.spec and scyld patch - for 2.6.32-220.4.1 Date: Tue, 31 Jan 2012 09:52:38 -0500 From: Adam Young <ayoung(a)redhat.com> To: John Hawkes <jhawkes(a)penguincomputing.com> On 01/31/2012 01:01 AM, John Hawkes wrote: > Well, I did consider adding the bproc stub into entry_64.S. It just > seemed easier to get things to work, first, and then fiddle with that > kind of thing second. Then it would be more obvious that I screwed > things up. And I hadn't thought out exactly how I wanted to do the > 'hook' into the bproc module. The entry_64.S stub_bproc would call > something bproc inside the main kernel, and that called routine would > likely be the thing that contains the source code hook to the proc > module. > > I continue to hassle with the startup of a new child thread on the > slave. I'm not convinced that the filecache is working right. I'm not > convinced of much of anything, actually. I'm really frustrated. > Tomorrow is a new day! I think I'll spend effort to instrument a rhel5 > filecache and see if my rhel6 filecache is doing similar reads. One way you can remove filecache from the mix is by using two virtual machines with a complete install on each. Disable file_cache and when you start up a new process on a compute node, it will just use the local copy of libraries. Don't use any of the scyld stuff to provision, just inject the kernel module into each side by hand, one as master, the other as slave, then run bpmaster and bpslave from the command line. I am assuming you are developing on Centos 6. There should be an application named virt_maanger (you might need to yum install it) that will let you create a new VM. Use a Centos6 iso as the install image, and boot the vm. Once it is up and running and through first boot, shut it down, and use the clone option from virt manager. Then you will have two vms that are identical except for the MAC address. It takes a little bit of CPU to work this way. For what you a are doing, one CPU per VM should be plenty. > > -- John > > > On Jan 30, 2012, at 5:59 PM, Adam Young<ayoung(a)redhat.com> wrote: > >> On 01/30/2012 04:54 PM, John Hawkes wrote: >>> I believe you're looking at the RHEL 4&5 bproc stub, not the RHEL 6, which is: >>> >>> #elif RHEL_MAJOR == 6 >>> __asm__( >>> " .text \n" >>> " .globl do_bproc_stub \n" >>> "do_bproc_stub: \n" >>> " sub $0x30,%rsp \n" >>> " callq save_rest \n" >>> " leaq 0x8(%rsp),%rcx \n" >>> " callq do_bproc \n" >>> " jmp ptregscall_common \n" >>> ); >>> >>> >>> The disassembly of stub_sigaltstack (which sets up for 2 args, plus >>> ptregs, vs. bproc which wants 3 args + ptregs): >>> sub $0x30,%rsp >>> callq ffffffff8100af70<save_rest> >>> lea 0x8(%rsp),%rdx >>> callq ffffffff8100ab20<sys_sigaltstack> >>> jmpq ffffffff8100b4a0<ptregscall_common> >>> nopl 0x0(%rax,%rax,1) >>> >>> So I was presuming that if 2 args uses %rdx, then 3 args uses %rcx.' >> Yes, I was. That looks a lot more correct. The PTREGS call puts the register to use for the ptregs into the arg param which is used for leaq 8(%rsp), \arg /* pt_regs pointer */ >> >> do_fork is defined like this: >> >> >> And PTREGSCALL stub_fork, sys_fork, %rdi >> >> The order of registers used in function calls should be: >> >> RDI, RSI, RDX, RCX, R8 and R9 >> >> And >> >> include/asm/syscalls.h:24:int sys_fork(struct pt_regs *); >> >> clone also seems to line up. >> >> PTREGSCALL stub_clone, sys_clone, %r8 >> long >> sys_clone(unsigned long clone_flags, unsigned long newsp, >> void __user *parent_tid, void __user *child_tid, struct pt_regs *regs) >> >> >> I'd almost say that you should move the code that does this kind of magic into entry_64.S and such, so you can make use of the real Kernel Macros. Copying it is problematic, and won't help it get into the Mainline anyway, and there is no reason not to do it the right way now, is there? >> >> >> >>> John >>> >>> On Mon, Jan 30, 2012 at 12:42 PM, Adam Young<ayoung(a)redhat.com> wrote: >>>> According to the top of tree Kernel, ptregs call (in entry_64.S, not >>>> entry.S anymore is: >>>> >>>> PARTIAL_FRAME 1 8 /* offset 8: return address */ >>>> subq $REST_SKIP, %rsp >>>> CFI_ADJUST_CFA_OFFSET REST_SKIP >>>> call save_rest >>>> DEFAULT_FRAME 0 8 /* offset 8: return address */ >>>> leaq 8(%rsp), \arg /* pt_regs pointer */ >>>> call \func >>>> jmp ptregscall_common >>>> CFI_ENDPROC >>>> >>>> >>>> Which leads me to think that sys_bproc should have something done before the >>>> call. >>>> >>>> >>>> You Have: >>>> " leaq do_bproc(%rip),%rax \n" >>>> " leaq -"__stringify(ARGOFFSET)"+8(%rsp), %rcx \n" >>>> " jmp ptregscall_common \ >>>> >>>> >>>> But I'd expect you need something more like: >>>> >>>> PARTIAL_FRAME 1 8 /* offset 8: return address */ >>>> subq $REST_SKIP, %rsp >>>> CFI_ADJUST_CFA_OFFSET REST_SKIP >>>> call save_rest >>>> DEFAULT_FRAME 0 8 /* offset 8: return address */ >>>> leaq 8(%rsp), \arg /* pt_regs pointer */ >>>> call \do_bproc(%rip),%rax >>>> jmp ptregscall_common >>>> CFI_ENDPROC >>>> >>>> >>>> >>>> >>>> >>>> On 01/27/2012 03:47 PM, John Hawkes wrote: >>>>> I'm thinking that my problem is that I'm not handling the pt_regs (et >>>>> al) correctly, so when the bproc kernel module code returns to user >>>>> state, things aren't right. I'm attaching the kernel/sysdep_x86_64.c >>>>> that I'm currently using, which has both the RHEL 4&5 code and the new >>>>> RHEL 6 code (managed by #defines). You can see I have separate >>>>> versions of bproc_kernel_thread, etc. >>>>> >>>>> John >>>>> >>>>> On Tue, Jan 24, 2012 at 11:56 AM, Adam Young<ayoung(a)redhat.com> wrote: >>>>>> On 01/24/2012 02:25 PM, John Hawkes wrote: >>>>>>> I'm attaching a tarball of rpms that should get you started. The >>>>>>> bproc is verbose with printk and syslog debugging messages. >>>>>>> The md5sum for the tarball: >>>>>>> 842e760a165d59a144425043e09bd888 >>>>>>> >>>>>>> john >>>>>> Thanks. I actually started a git repo based on the Linus tree and >>>>>> started >>>>>> applying it. But I will take this and run with it as well. I tried to >>>>>> build the Kernel in a VM, but ran out of disk space, so' I'll need to >>>>>> expand it later. >>>>>> >>>>>> I talked quickly with Kyle earlier today. He said that the biggest >>>>>> difference between the RHEL 5 and RHEL6 Kernel was the removal of PT >>>>>> regs. >>>>>> This is probably no surprise to you, but it was to me. This commit is >>>>>> probably the best explanation for it, or at least a good starting point. >>>>>> It >>>>>> is old enough that I can't find a pointer to it on gitweb, so I included >>>>>> the commit message en toto. >>>>>> >>>>>> commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5 >>>>>> Author: David Howells<dhowells(a)redhat.com> >>>>>> Date: Thu Oct 5 14:55:46 2006 +0100 >>>>>> >>>>>> >>>>>> http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git&a=sear… >>>>>> >>>>>> >>>>>> IRQ: Maintain regs pointer globally rather than passing to IRQ >>>>>> handlers >>>>>> >>>>>> Maintain a per-CPU global "struct pt_regs *" variable which can be >>>>>> used >>>>>> instead >>>>>> of passing regs around manually through all ~1800 interrupt handlers >>>>>> in >>>>>> the >>>>>> Linux kernel. >>>>>> >>>>>> The regs pointer is used in few places, but it potentially costs both >>>>>> stack >>>>>> space and code to pass it around. On the FRV arch, removing the regs >>>>>> parameter >>>>>> from all the genirq function results in a 20% speed up of the IRQ exit >>>>>> path >>>>>> (ie: from leaving timer_interrupt() to leaving do_IRQ()). >>>>>> >>>>>> Where appropriate, an arch may override the generic storage facility >>>>>> and >>>>>> do >>>>>> something different with the variable. On FRV, for instance, the >>>>>> address >>>>>> is >>>>>> maintained in GR28 at all times inside the kernel as part of general >>>>>> exception >>>>>> handling. >>>>>> >>>>>> >>>>>> >>>>>> Having looked over the code, it appears that the parameter may be >>>>>> handed >>>>>> down >>>>>> through up to twenty or so layers of functions. Consider a USB >>>>>> character >>>>>> device attached to a USB hub, attached to a USB controller that posts >>>>>> its >>>>>> interrupts through a cascaded auxiliary interrupt controller. A >>>>>> character >>>>>> device driver may want to pass regs to the sysrq handler through the >>>>>> input >>>>>> layer which adds another few layers of parameter passing. >>>>>> PARTIAL_FRAME 1 8 /* offset 8: return address */ >>>>>> subq $REST_SKIP, %rsp >>>>>> CFI_ADJUST_CFA_OFFSET REST_SKIP >>>>>> call save_rest >>>>>> DEFAULT_FRAME 0 8 /* offset 8: return address */ >>>>>> leaq 8(%rsp), \arg /* pt_regs pointer */ >>>>>> call \func >>>>>> jmp ptregscall_common >>>>>> CFI_ENDPROC >>>>>> >>>>>> I've build this code with allyesconfig for x86_64 and i386. I've >>>>>> runtested the >>>>>> main part of the code on FRV and i386, though I can't test most of the >>>>>> drivers. >>>>>> I've also done partial conversion for powerpc and MIPS - these at >>>>>> least >>>>>> compile >>>>>> with minimal configurations. >>>>>> >>>>>> This will affect all archs. Mostly the changes should be relatively >>>>>> easy. >>>>>> Take do_IRQ(), store the regs pointer at the beginning, saving the old >>>>>> one: >>>>>> >>>>>> struct pt_regs *old_regs = set_irq_regs(regs); >>>>>> >>>>>> And put the old one back at the end: >>>>>> >>>>>> set_irq_regs(old_regs); >>>>>> >>>>>> Don't pass regs through to generic_handle_irq() or __do_IRQ(). >>>>>> >>>>>> In timer_interrupt(), this sort of change will be necessary: >>>>>> >>>>>> - update_process_times(user_mode(regs)); >>>>>> - profile_tick(CPU_PROFILING, regs); >>>>>> + update_process_times(user_mode(get_irq_regs())); >>>>>> + profile_tick(CPU_PROFILING); >>>>>> >>>>>> I'd like to move update_process_times()'s use of get_irq_regs() into >>>>>> itself, >>>>>> except that i386, alone of the archs, uses something other than >>>>>> user_mode(). >>>>>> >>>>>> Some notes on the interrupt handling in the drivers: >>>>>> >>>>>> (*) input_dev() is now gone entirely. The regs pointer is no longer >>>>>> stored in >>>>>> the input_dev struct. >>>>>> >>>>>> (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It >>>>>> does >>>>>> something different depending on whether it's been supplied with >>>>>> a >>>>>> regs >>>>>> pointer or not. >>>>>> >>>>>> (*) Various IRQ handler function pointers have been moved to type >>>>>> irq_handler_t. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>

1 0

Fwd: Re: /bpfs
by Adam Young 09 Feb '12

09 Feb '12

Some old mails that should have been sent to the list -------- Original Message -------- Subject: Re: /bpfs Date: Wed, 1 Feb 2012 11:04:57 -0800 From: John Hawkes <jhawkes(a)penguincomputing.com> To: Adam Young <ayoung(a)redhat.com> I figured it out. Yes, an explicit mount is required. It doesn't look like this explicit mount occurs in RHEL 4&5, but ... I press onward, and I'll figure that out later. So now I've got the /bpfs to seemingly work correctly on the RHEL 6 slave. Now I'll work on why my simple bproc_move() program is segfaulting. It does execute in usermode -- it can perform a syscall(__NR_bproc) to read the bproc version number, but a syslog() causes a segfault. If I eliminate the syslog(), then a call to bproc_currnode() works. And if I add a printf() at the end, it prints the return value from bproc_currnode(). Alas, running this a 2nd time causes a segfault. I'm trying to puzzle out why it works sometimes and fails other times. John On Wed, Feb 1, 2012 at 10:42 AM, Adam Young<ayoung(a)redhat.com> wrote: > I really don't remember much about bpfs at all, except for the feeling that > is was a mistake, and we should have been using sysfs instead. I was half > convinced that we should roll it back to the way it was in the bproc code > prior to moving to the 2.6 Linux Kernel, but thought it might be easier to > move forward than to move back. > > As I recall, an explicit mount was required, but that is really faded in my > memory. > > > > On 01/31/2012 09:12 PM, John Hawkes wrote: >> >> I change the /bpfs to behave a bit more like /proc, in that after the >> register_filesystem(), the bpfs code also does a kern_mount_data(), >> which does the mount, which gets into bpfs_get_sb() and then (because >> the MS_KERNMOUNT flag is set) does the bpfs_fill_super(). On the >> master node, /etc/init.d/beowulf does an explicit mount, which I think >> gets into bpfs_get_sb() a 2nd time, but now the MS_KERNMOUNT flag is >> off. >> >> On the slave, the the same MS_KERNMOUNT flag is seen by bpfs_get_sb(), >> and the same bpfs_fill_super(), and no 2nd mount is seen (at least not >> until the /etc/beowulf/fstab may do it, which would be unnecessary). >> >> But the readdir() still looks bad on the slave. >> >> On the master: >> >> readdir('/bpfs') ino:1 name:'.' >> readdir('/bpfs') ino:1 name:'..' >> readdir('/bpfs') ino:8 name:'self' >> readdir('/bpfs') ino:13 name:'-1' >> readdir('/bpfs') ino:11 name:'status' >> >> which is what I expect. >> But on the slave (after I've registered various nodes): >> >> readdir('/bpfs') ino:4018 name:. >> readdir('/bpfs') ino:3982 name:.. >> stat('/bpfs/0') fails:2(No such file or directory) >> stat('/bpfs/-1') fails:2(No such file or directory) >> stat('/bpfs/self') fails:2(No such file or directory) >> >> So I've still got a big problem to solve. >> >> john >> >> >> On Tue, Jan 31, 2012 at 4:15 PM, John Hawkes >> <jhawkes(a)penguincomputing.com> wrote: >>> >>> So I think what the slave problem is ... is that nothing does an >>> actual mount of /bpfs. The /bpfs filesystem gets registered, but >>> nothing triggers a call to get the superblock or (because of that) to >>> fill the superblock. >>> >>> I see that the /proc filesystem calls kern_mount_data(). Perhaps the >>> slave side needs to do that. On the master side, the >>> /etc/init.d/beowulf script issues a mount command. >>> >>> john >>> >>> I rewrote much of the /bpfs code for RHEL 6.2, by the way, because >>> there were lots of changes in the vfs layer. >>> >>> On Tue, Jan 31, 2012 at 3:53 PM, John Hawkes >>> <jhawkes(a)penguincomputing.com> wrote: >>>> >>>> Apparently I have problems with my port of the /bpfs code, too. >>>> >>>> Things seem to be working pretty well for the master, but on the slave >>>> the behavior is strange. I discovered this while trying to understand >>>> why /bpfs/self wasn't being seen on the slave. I've got the >>>> kmod-bproc bpfs code instrumented to be verbose, and I do see the >>>> various /bpfs/ namespace entries being created, but they aren't being >>>> seen by user-level code. >>>> >>>> So I added a few lines to bpmaster and to bpslave, at the appropriate >>>> spots after the /bpfs was set up, to do: >>>> opendir("/rootfs") >>>> then readdir() >>>> and these both succeed on master and slave (although I haven't looked >>>> at what gets returned by readdir). However, on the master, I see a >>>> call to bpfs_root_readdir(), as expected, but I do *not* see this on >>>> the slave, even though both master and slave bpfs code use the same >>>> struct and the same inode and file operations. >>>> >>>> As you might expect, after the readdir() I do: >>>> stat("/bpfs/-1") >>>> etc. on the master, and >>>> stat("/bpfs/-1") >>>> on the slave... the master sees a successful stat() of all the names >>>> that I expect to be there, but on the slave the stat() calls fail. >>>> And nothing in the bpfs code seems to be called. So I conclude that >>>> the /bpfs on the master gets set up as I expect, but on the slave it >>>> doesn't get set up correctly... even though I'm doing the same >>>> operations on both for the /bpfs root and the superblock. >>>> >>>> Weird. >>>> >>>> I hope this isn't part of something subtle with the /rootfs being used >>>> as the temporary root during the initial phases of the slave boot. >>>> >>>> John > >

1 0

Re: [Bproc] sysdep-x86_64.c seems likely broken
by Adam Young 09 Feb '12

09 Feb '12

On 02/06/2012 02:55 PM, John Hawkes wrote: > Hi Adam, > > An FYI ... I continue to be stuck. > > A simple program that does a bproc_move() from the master to the > slave, prints to stdout, then does another bproc_move() back to the > master sometimes works, although if I run it repeatedly in a while > loop, it eventually hangs or gets a segv deep in kernel code (in > different areas). > > Doing a bpsh of a program fails all the time - with that bad exit > status. That tells me something is probably wrong with the various > asm routines (bproc_kernel_thread, bproc_child_rip, etc.). Problem > is, I don't fully understand how all those asm routines work, so this > has been a long slog. And a very frustrating one. > > John

1 0

Fwd: Re: /bpfs
by Adam Young 02 Feb '12

02 Feb '12

Reposting to BProc list I figured it out. Yes, an explicit mount is required. It doesn't look like this explicit mount occurs in RHEL 4&5, but ... I press onward, and I'll figure that out later. So now I've got the /bpfs to seemingly work correctly on the RHEL 6 slave. Now I'll work on why my simple bproc_move() program is segfaulting. It does execute in usermode -- it can perform a syscall(__NR_bproc) to read the bproc version number, but a syslog() causes a segfault. If I eliminate the syslog(), then a call to bproc_currnode() works. And if I add a printf() at the end, it prints the return value from bproc_currnode(). Alas, running this a 2nd time causes a segfault. I'm trying to puzzle out why it works sometimes and fails other times. It might be interesting to look at what is going across the wire. Can you do a BProc move from the head node, to a compute node, and then back to the head node? The printf might be an issue with the 3 magic file handles used to forward stdin stdout and stderr. Another possibility then is to open a file in /tmp and write status there. Did you mean that running bproc_currnode twice also generates a segfault?

2 2

Future Work
by Adam Young 12 Jan '11

12 Jan '11

Looking for feedback on the preferred platform for BProc support: RHEL5, RHEL6, Fedora 15.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Bproc