Displaying 14 results from an estimated 14 matches for "first1".
Did you mean:
first
2002 May 16
4
rsynch related question
Hello,
I had a question on rsynch'ing, please do help me on this,
I have scenario where,I need to synch the two softwares, where both
the software are across the network, on different cells( AFS cells).
For ex: first1 - /afs/tr/software , second1 - /afs/ddc/software
Both the softwares are same & fist1 cell will be constantly
updating and I need to synch this software to sencond1. In this scenario
what command I should use ?
I will appreciate your great help.
Thanks in advance
Thanks
Uma
2012 Jun 13
2
[LLVMdev] Assert in live update from MI scheduler.
...g6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6
> JMP <BB#2>
> Successors according to CFG: BB#2 BB#1
>
> BB#2: derived from LLVM BB %for.end
> Predecessors according to CFG: BB#1
> %vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any pointer") IntRegs:%vreg7,%vreg1
> STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7
> %vreg8<def> = IMPLICIT_DEF; IntRegs:%vreg8
> %R0<def> = COPY %vreg8<kill>; IntRegs:...
2003 Apr 17
1
Odd error: Physical size does not match superblock size
...est
partition on each (/dev/hda3 and /dev/hdb3, 96GB each) was mirrored in a
linux software RAID-1 configuration.
It was running fine for many months. Then I updated the kernel and
needed to reboot accordingly. (2.4.18-14.8.0smp -> 2.4.18-27.8.0smp)
Problem:
Upon a reboot, fsck complained that /first1 (/dev/hda3)'s superblock or
partition table reported 25712032 blocks, while the physical disk
reported 25712016. (a difference of 16). I tested with new and old
kernel, and the error occured on both.
I tried fsck and e2fsck passes with varied options on /dev/hda3
(/first1) to hopefully fix the...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...reg10
JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6
JMP <BB#2>
Successors according to CFG: BB#2 BB#1
BB#2: derived from LLVM BB %for.end
Predecessors according to CFG: BB#1
%vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any
pointer") IntRegs:%vreg7,%vreg1
STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any
pointer") IntRegs:%vreg7
JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef>
If loop never iterates, vreg10 and vreg1...
2005 Jan 26
9
Cisco 7960 Message Light on multiple phones
...iend
username=100
secret=100
host=dynamic
mailbox=100
linelabel="First Last"
line => 102
[135]
type=friend
username=135
secret=135
host=dynamic
mailbox=135
linelabel="HelpDesk"
line => 135
[101]
type=friend
username=101
secret=101
host=dynamic
mailbox=101
linelabel="First1 Last1"
callerid="First1 Last1" <101>
line => 101
2012 Jun 14
1
[LLVMdev] Assert in live update from MI scheduler.
...g6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6
> JMP <BB#2>
> Successors according to CFG: BB#2 BB#1
>
> BB#2: derived from LLVM BB %for.end
> Predecessors according to CFG: BB#1
> %vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any pointer") IntRegs:%vreg7,%vreg1
> STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7
> JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef>
>
> If loop never iterates, v...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...vreg2
JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6
JMP <BB#2>
Successors according to CFG: BB#2 BB#1
BB#2: derived from LLVM BB %for.end
Predecessors according to CFG: BB#1
%vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any
pointer") IntRegs:%vreg7,%vreg1
STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any
pointer") IntRegs:%vreg7
%vreg8<def> = IMPLICIT_DEF; IntRegs:%vreg8
%R0<def> = COPY %vreg8<kill>; IntRegs:%vreg8...
2012 Jun 13
2
[LLVMdev] Assert in live update from MI scheduler.
On Jun 13, 2012, at 10:49 AM, Sergei Larin <slarin at codeaurora.org> wrote:
> So if this early exit is taken:
>
> // SSA defs do not have output/anti dependencies.
> // The current operand is a def, so we have at least one.
> if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end())
> return;
>
> we do not ever get to this point:
>
>
2012 Jun 12
2
[LLVMdev] Assert in live update from MI scheduler.
...ot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6
192B JMP <BB#2>
Successors according to CFG: BB#2 BB#1
208B BB#2: derived from LLVM BB %for.end
Predecessors according to CFG: BB#1
224B %vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any
pointer") IntRegs:%vreg7,%vreg1
240B STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>;
mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7
256B JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef>
Hexagon MI scheduler is working with B...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...B#1>, %PC<imp-def>; PredRegs:%vreg6
> 192B JMP <BB#2>
> Successors according to CFG: BB#2 BB#1
>
> 208B BB#2: derived from LLVM BB %for.end
> Predecessors according to CFG: BB#1
> 224B %vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any
> pointer") IntRegs:%vreg7,%vreg1
> 240B STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>;
> mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7
> 256B JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef>
>
> Hexagon...
2012 Jun 11
0
[LLVMdev] scoreboard hazard det. and instruction groupings
On Jun 11, 2012, at 12:07 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> Looking at VLIWPacketizerList::PacketizeMIs, it seems like the
> instructions are first scheduled (via some external scheme?), and then
> packetized 'in order'. Is that correct?
Anshu?
> In the PowerPC grouping scheme, resources are assigned on a group
> basis (by the instruction dispatching
2012 Jun 13
4
[LLVMdev] Assert in live update from MI scheduler.
...egs:%vreg6
> > 192B JMP <BB#2>
> > Successors according to CFG: BB#2 BB#1
> >
> > 208B BB#2: derived from LLVM BB %for.end
> > Predecessors according to CFG: BB#1
> > 224B %vreg7<def> = LDriw %vreg1<kill>, 0;
> mem:LD4[%first1](tbaa=!"any
> > pointer") IntRegs:%vreg7,%vreg1
> > 240B STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>;
> > mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7
> > 256B JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef>...
2012 Jun 11
3
[LLVMdev] scoreboard hazard det. and instruction groupings
On Mon, 11 Jun 2012 10:48:18 -0700
Andrew Trick <atrick at apple.com> wrote:
> On Jun 11, 2012, at 9:30 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> > I'm considering writing more-detailed itineraries for some PowerPC
> > CPUs that use the 'traditional' instruction grouping scheme. In
> > essence, this means that multiple instructions will stall
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...MP <BB#2>
> > > Successors according to CFG: BB#2 BB#1
> > >
> > > 208B BB#2: derived from LLVM BB %for.end
> > > Predecessors according to CFG: BB#1
> > > 224B %vreg7<def> = LDriw %vreg1<kill>, 0;
> > mem:LD4[%first1](tbaa=!"any
> > > pointer") IntRegs:%vreg7,%vreg1
> > > 240B STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>;
> > > mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7
> > > 256B JMPR %PC<imp-def>, %R31<imp-use>, %R0&...