Christoph Hellwig píše v So 09. 02. 2008 v 00:04 -0500:
> On Fri, Feb 08, 2008 at 02:46:25PM -0800, Luck, Tony wrote:
> > Petr Tesarik (3):
> > [IA64] Rename TIF_PERFMON_WORK back to TIF_NOTIFY_RESUME
> > [IA64] Synchronize kernel RSE to user-space and back
> > [IA64] Synchronize
On Fri, Feb 08, 2008 at 02:46:25PM -0800, Luck, Tony wrote:
> Petr Tesarik (3):
> [IA64] Rename TIF_PERFMON_WORK back to TIF_NOTIFY_RESUME
> [IA64] Synchronize kernel RSE to user-space and back
> [IA64] Synchronize RBS on PTRACE_ATTACH
This is still not killing the now unessecary
On Wed, Feb 06, 2008 at 09:37:54AM -0800, Luck, Tony wrote:
> > Any reason the various ptrace bits are not included in this pull?
>
> The ptrace bits depend upon some generic changes to add arch_ptrace_stop()
> ... I think Andrew included them as part 89/260 of today's early
> morning mail patch b
On Wed, 2008-02-06 at 09:37 -0800, Luck, Tony wrote:
> > Any reason the various ptrace bits are not included in this pull?
>
> The ptrace bits depend upon some generic changes to add arch_ptrace_stop()
> ... I think Andrew included them as part 89/260 of today's early
> morning mail patch bomb.
Y
> Any reason the various ptrace bits are not included in this pull?
The ptrace bits depend upon some generic changes to add arch_ptrace_stop()
... I think Andrew included them as part 89/260 of today's early
morning mail patch bomb.
-Tony
-
To unsubscribe from this list: send the line "unsubscri
On Tue, Feb 05, 2008 at 10:10:40AM -0800, Luck, Tony wrote:
> Hi Linus,
>
> please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
>
> This will update the files shown below.
Any reason the various ptrace bits are not included in this pull?
-
To un
> I thought you already generated the diffstat with "git diff --stat", and
> if so, just adding "--summary" should do it.
My script was written in the early hours (well weeks) of git history. Perhaps
I didn't know about "--stat" or maybe it didn't exist yet. The script
currently just pipes "git-w
On Mon, 10 Dec 2007, Luck, Tony wrote:
>
> Should I update my script that makes the "Please pull" message.
It should be added automatically to the diffstat if you create the
diffstat with
git diff -C --stat --summary linus...release
(that triple dot creates the diff from the last com
> Hmm. It also did:
>
> mode change 100755 => 100644 arch/ia64/scripts/unwcheck.py
Should I update my script that makes the "Please pull" message.
Right now it just uses "git whatchanged release ^linus | git-shortlog"
which doesn't mention any mode changes ... thus your understandable
confusion
> makes the Makefile work even for a non-executable file for when you use
> inferior tools, but does that mean that we should have thrown away the
> information that it *is* an executable file when not using those inferior
> tools?
Once I added the "python " in front of the name in the Makefi
On Mon, 10 Dec 2007, Luck, Tony wrote:
>
> This will update the files shown below.
>
> ..
> 16 files changed, 56 insertions(+), 53 deletions(-)
Hmm. It also did:
mode change 100755 => 100644 arch/ia64/scripts/unwcheck.py
was that really intentional?
Sure, the commit itself:
> Andrew Mort
Hi Linus,
Another day, another buildfix, another git pull ...
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below.
Thanks!
-Tony
arch/ia64/kernel/machine_kexec.c |4 +++-
1 file changed, 3 insertions(+
Hi Linus,
And another quick pull to fix an ia64 UP build problem.
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
Or since git is updating slowly right now, from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
rel
Hi Linus,
Another quick pull to fix the ia64 build problem introduced by some
header file re-arrangements elsewhere in the tree.
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
Or since git is updating slowly right now, from:
ssh://mas
On Sat, 1 Sep 2007, Luck, Tony wrote:
>
> Note to anyone else using my GIT tree ... this means my tree jumped
> sideways and you won't be able to pull from it if you had done a pull
> since Thursday. You'll have to back the branch you use to track my
> tree back up (e.g. to v2.6.23-rc4) before
Hi Linus,
I backed up my tree to before the evil HPET disable commit, and then
cherry-picked the stuff that follwed. So here's the revised pull without
the stupidity.
Note to anyone else using my GIT tree ... this means my tree jumped
sideways and you won't be able to pull from it if you had don
> Having looked closer, it looks like the magic actually disables some
> broken code from happening on other architectures.
Yes. The drivers/char/hpet.c clocksource code was added for ia64 as
part of the switch from the time interpolator to the generic clock
code ... but the patch had languished
On Fri, 2007-08-31 at 01:37 -0700, Linus Torvalds wrote:
>
> On Thu, 30 Aug 2007, Linus Torvalds wrote:
> >
> > So there are two cases:
> >
> > - either the code is already only used on ia64, and nobody else will
> >care.
> >
> >In this case, the patch is pointless.
> >
> > - or it'
On Fri, 2007-08-31 at 01:37 -0700, Linus Torvalds wrote:
> It would appear that what you actually wanted to happen in that commit was
> to make sure that the clocksource didn't get registered. If so, the
> logical patch would be something like the appended instead, which would
> disable the code
On Thu, 30 Aug 2007, Linus Torvalds wrote:
>
> So there are two cases:
>
> - either the code is already only used on ia64, and nobody else will
>care.
>
>In this case, the patch is pointless.
>
> - or it's used by others, and others *will* care, and (judging by the
>probably i
On Thu, 30 Aug 2007, Luck, Tony wrote:
>
> This will update the files shown below. The change to drivers/char/hpet.c
> makes the hpet timer code there ia64 only until we can do something better
> to merge in arch/{i386,x86_64)/kernel/hpet.c
That's crazy. The patch in question looks like this:
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below. The change to drivers/char/hpet.c
makes the hpet timer code there ia64 only until we can do something better
to merge in arch/{i386,x86_64)/kernel
On Fri, 20 Jul 2007, Luck, Tony wrote:
>
> This will update the files shown below. I'm touching a few
> non-ia64 files (they are at the bottom of the diffstat) in here
> to delete the CONFIG_TIME_INTERPOLATION code that nobody except
> ia64 used.
Thanks. That timekeeping duplication was confus
On Tue, 2007-05-08 at 15:26, Simon Horman wrote:
> On Tue, May 08, 2007 at 09:13:18AM +0800, Zou Nan hai wrote:
> >
> > Hi Tony,
> > If the per-cpu TR entry is removed,
> > I think the relocate_kernel.S also need a fix to remove the
> per-cpu TR
> > purge code.
>
> Just to clarify, i
On Tue, May 08, 2007 at 09:13:18AM +0800, Zou Nan hai wrote:
>
> Hi Tony,
> If the per-cpu TR entry is removed,
> I think the relocate_kernel.S also need a fix to remove the per-cpu
> TR
> purge code.
Just to clarify, is this what you are thinking about?
If so, it seems sensible
On Tue, 2007-05-08 at 00:54, Luck, Tony wrote:
> [Repost ... this seems to have been eaten by the internet, it
> didn't show up on the mailing list either].
>
> Hi Linus,
>
> please pull from:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> release
>
> This will
include/asm-ia64/swiotlb.h |9 --
arch/ia64/ia32/sys_ia32.c| 10 +-
arch/ia64/kernel/efi.c | 36
arch/ia64/kernel/perfmon.c | 11 +-
arch/ia64/kernel/setup.c | 30 +++
arch/ia64/lib/Makefile |3
arch/ia64/mm/contig.c|5 -
arch/ia64/
> Tony Luck:
> [IA64] enable trap code on slot 1
Oops ... this patch really belongs to Bibo Mao. I must have goofed in
git when I added the teeny comment to include/asm-ia64/break.h to note
that __IA64_BREAK_KPROBE uses the whole range 0x81000-0x81fff of break
numbers and forgot to use "--au
> Biggest part of this is the kexec/kdump changes (which include a teeny generic
> change to add an icache flush option to kernel/kexec.c).
There are a few more patches in the queue that I'll be piling together
for another pull ... but I wanted to get the kexec/kdump monster out
of the way (it nee
Tony Luck wrote:
>
> MCA testing is somewhat harder as it requires specialized h/w
> and/or s/w to inject the error. But I know that some of you can
> do this ... so I'd like to hear what happens.
I've run the memory error injection code with Keith's patch
without any noticeable regression. I v
>What testing would you like to see?
As much testing as possible :-)
I think most platforms have some way to generate an INIT (either
a front panel button like on Tiger, or by asking the maintenance
processor to generate one). So it would be good to hear an Ack
from as many different platforms a
On Tue, Aug 30, 2005 at 08:56:25PM -0700, Tony Luck wrote:
> On 8/30/05, Keith Owens <[EMAIL PROTECTED]> wrote:
> > Tony, can you give some indication on your plans for my MCA/INIT
> > rewrite? Will you send it to Linus in the next couple of weeks or will
> > it have to wait for 2.6.15 to open?
>
On 8/30/05, Keith Owens <[EMAIL PROTECTED]> wrote:
> Tony, can you give some indication on your plans for my MCA/INIT
> rewrite? Will you send it to Linus in the next couple of weeks or will
> it have to wait for 2.6.15 to open?
Keith,
It is a big enough piece that I don't expect to get to dig t
On Tue, 30 Aug 2005 16:27:41 -0700,
"Luck, Tony" <[EMAIL PROTECTED]> wrote:
>Hi Linus,
>
>please pull from:
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> release
Tony, can you give some indication on your plans for my MCA/INIT
rewrite? Will you send it to Linu
34 matches
Mail list logo
