On Jan 10, 2008 2:37 AM, Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:
> On 1/10/08, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > I'm already cloning the branches; the problem is not getting conflicts etc.
> > when updating.
>
> Isn't git pull --force what you are looking for?
>
> Ciao,
> --
> Paolo
>
On 1/10/08, Andi Kleen <[EMAIL PROTECTED]> wrote:
> I'm already cloning the branches; the problem is not getting conflicts etc.
> when updating.
Isn't git pull --force what you are looking for?
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
--
To unsubscribe from this list: send the li
On 2008.01.09 23:41:42 +0100, Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 02:35:55PM -0800, Harvey Harrison wrote:
> > On Wed, 2008-01-09 at 23:28 +0100, Andi Kleen wrote:
> >
> > > Do you have a simple recipe to just update from the the remote branch,
> > > assuming there are no local changes or
On Wed, Jan 09, 2008 at 02:35:55PM -0800, Harvey Harrison wrote:
> On Wed, 2008-01-09 at 23:28 +0100, Andi Kleen wrote:
>
> > Do you have a simple recipe to just update from the the remote branch,
> > assuming there are no local changes or local branches?
> >
> > -Andi
>
> For staying up to dat
On Wed, 2008-01-09 at 23:28 +0100, Andi Kleen wrote:
> Do you have a simple recipe to just update from the the remote branch,
> assuming there are no local changes or local branches?
>
> -Andi
For staying up to date I use the following:
# Add Linus's tree as a remote
git remote --add linus
git
On Wed, Jan 09, 2008 at 11:09:48PM +0100, Björn Steinbrink wrote:
> On 2008.01.09 18:48:00 +0100, Andi Kleen wrote:
> > On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote:
> > > then you have a truly ancient x86.git repository ;-)
> >
> > I update only infrequently because frankly git's r
On 2008.01.09 18:48:00 +0100, Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote:
> > then you have a truly ancient x86.git repository ;-)
>
> I update only infrequently because frankly git's remote branch tracking
> is a mess. At least it doesn't really work for x86#m
Andi Kleen wrote:
People tend to make jokes about optimizing the idle loop too, but they're
actually wrong. Exit latency for the idle loop is important -- it
decides how quickly you can react to load changes on idle CPUs.
For short udelays I suspect shorter exit latency is also moderately use
On Wed, Jan 09, 2008 at 12:25:59PM -0800, Arjan van de Ven wrote:
> On Wed, 9 Jan 2008 18:48:00 +0100
> > And after all that's still by far the most common system call
> > (not only for databases; i profiled this using systemtap in some
> > loads some time ago and it usually came up with >50%)
> >
On Wed, 9 Jan 2008 18:48:00 +0100
> And after all that's still by far the most common system call
> (not only for databases; i profiled this using systemtap in some
> loads some time ago and it usually came up with >50%)
> and quite important for many workloads.
>
btw be careful with this; the X
On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Jan 09, 2008 at 04:22:08PM +0100, Ingo Molnar wrote:
> > >
> > > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
> > > > > nope, it's a 64-bit setup/dependency bug/problem: the v
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 04:22:08PM +0100, Ingo Molnar wrote:
> >
> > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > > nope, it's a 64-bit setup/dependency bug/problem: the vsyscall mappings
> > > > are installed via an __initcall, and that's too lat
On Wed, Jan 09, 2008 at 04:22:08PM +0100, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > nope, it's a 64-bit setup/dependency bug/problem: the vsyscall mappings
> > > are installed via an __initcall, and that's too late for early use. The
> > > combo patch below fixed th
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > nope, it's a 64-bit setup/dependency bug/problem: the vsyscall mappings
> > are installed via an __initcall, and that's too late for early use. The
> > combo patch below fixed the crash for me, does it work on your box too?
>
> That gives
>
> /home/
> nope, it's a 64-bit setup/dependency bug/problem: the vsyscall mappings
> are installed via an __initcall, and that's too late for early use. The
> combo patch below fixed the crash for me, does it work on your box too?
That gives
/home/lsrc/quilt/linux/arch/x86/kernel/setup_64.c: In function
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Unfortunately simply adding __vsyscall_fn to native_read_tsc doesn't
> work -- causes early kernel faults like
>
> PANIC: early exception rip ff600105 error 10 cr2 ff600105
> Pid: 0, comm: swapper Not tainted 2.6.24-rc6 #58
>
> Call Tra
> I think the problem is that the vsyscall/vdso code calls it through
> vread and for that it has to be exported. There seems to be also
> another bug with the old style vsyscalls not using the TSC vread
> that masks it on older glibc
>
> Stepping with gdb through old style vgettimeofday() confirm
17 matches
Mail list logo
