> On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote:
> > > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
> > > and [5] is also needed.
> >
> > It's not. The utrace_regset for the debugregs already has that behavior
> > for those two words, so mapping all 8 uare
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote:
> > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
> > and [5] is also needed.
>
> It's not. The utrace_regset for the debugregs already has that behavior
> for those two words, so mapping all 8 uarea words to t
> Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
> and [5] is also needed.
It's not. The utrace_regset for the debugregs already has that behavior
for those two words, so mapping all 8 uarea words to the regset is fine.
Thanks,
Roland
-
To unsubscribe from this list: send
On Tue, Feb 13, 2007 at 04:05:30PM +0300, Alexey Dobriyan wrote:
> On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
> > > 2. The following proggie renders box unusable in ~10 seconds (but not
> > >mainline kernel where Ctrl+C will kill process).
> >
> > I haven't been able to rep
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
> > We're aware of two regressions compared to mainline if ptrace is utrace:
>
> Thanks very much for bringing these to my attention.
>
> > 1) zero holes for PTRACE_PEEKUSR vanished.
>
> I've fixed this in the current patches.
Looking
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
> > 2. The following proggie renders box unusable in ~10 seconds (but not
> >mainline kernel where Ctrl+C will kill process).
>
> I haven't been able to reproduce this so far on my test machine. I got
> bored after about 10 minute
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> > As to the size of the MCE code doing everything EDAC K8 does, that
> is
> > mostly true. BUT then the x86_64 MCE mechanism becomes the
> exception
> > path.
>
> Sorry you lost me on that one.
>
> -Andi
In similiar manner of the original SATA driver
> I am currently developing enhancements to EDAC that provide for L1, L2,
> etc cache ECC event harvesting,
mce.c + mcelog do that already for all x86-64 cpus because
that's all reported as standard x86 machine checks.
> DMA ECC event harvest, interconnect
> harvesting, and other chipset/proces
> We're aware of two regressions compared to mainline if ptrace is utrace:
Thanks very much for bringing these to my attention.
> 1) zero holes for PTRACE_PEEKUSR vanished.
I've fixed this in the current patches.
> 2. The following proggie renders box unusable in ~10 seconds (but not
>mainl
On Sat, Feb 10, 2007 at 11:04:48AM -0600, Robert Hancock wrote:
> Frederik Deweerdt wrote:
> >>How about this one instead then:
> >Well, the warning you get is not that obvious:
> >test.c: In function 'main':
> >test.c:11: warning: 'deprecated_irqf' is deprecated
> >And as far as I could test
...
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> Alan <[EMAIL PROTECTED]> writes:
>
> > Please just push the EDAC K8 stuff. Andi will say "no" from now
> until the
> > end of time, but end users want it, distributions want it, and Andi
> is
> > not the EDAC maintainer so should consider himself overr
From: Ralf Baechle <[EMAIL PROTECTED]>
On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote:
> Which remembers me that I think that MIPS is using the non-compat version
> of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat
> syscall for some reason. Dunno.
Whic
> utrace-utrace-tracehook.patch
> utrace-utrace-tracehook-ia64.patch
> utrace-utrace-tracehook-sparc64.patch
> utrace-utrace-tracehook-s390.patch
> utrace-utrace-regset.patch
> utrace-utrace-regset-ia64.patch
> utrace-utrace-regset-sparc64.patch
> utrace-utrace-regset-s390.patch
> utrace-utrace-cor
On Sun, Feb 11, 2007 at 05:14:46PM +0100, Heiko Carstens wrote:
> Hmm.. so you don't need to do some fancy compat conversion for the sigset_t
> that gets passed? Why is that? I don't get it...
Ah, I finally get your point. Yes, that needs conversion.
Ralf
-
To unsubscribe from this list: send
On Sun, Feb 11, 2007 at 04:33:41PM +0100, David Woodhouse wrote:
> On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote:
> > Unfortunately struct epoll_event contains a gap so it bets on identical
> > padding rules between native and compat ABI and anyway, padding is wasted
> > space so the struc
On Sun, 11 Feb 2007, Heiko Carstens wrote:
> On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote:
> > On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote:
> >
> > > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote:
> > > > Which remembers me that I think that MIPS is u
On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote:
> On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote:
>
> > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote:
> > > Which remembers me that I think that MIPS is using the non-compat version
> > > of sys_epoll_pwait f
On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote:
> Unfortunately struct epoll_event contains a gap so it bets on identical
> padding rules between native and compat ABI and anyway, padding is wasted
> space so the struct members should have been swapped when this structure
> was created. Oh
On Saturday 10 February 2007 22:05, Ralf Baechle wrote:
> On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote:
>
> > Which remembers me that I think that MIPS is using the non-compat version
> > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat
> > syscall for
On Sat, 10 Feb 2007, Ralf Baechle wrote:
> Unfortunately struct epoll_event contains a gap so it bets on identical
> padding rules between native and compat ABI and anyway, padding is wasted
> space so the struct members should have been swapped when this structure
> was created. Oh well, too lat
On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote:
> On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote:
> > Which remembers me that I think that MIPS is using the non-compat version
> > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat
> > syscall for
On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote:
> Which remembers me that I think that MIPS is using the non-compat version
> of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat
> syscall for some reason. Dunno.
Which reminds me that x86_64 i386 compat doe
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote:
>
> I'm getting fed up of holding onto hundreds of patches against subsystem
> trees, sending them over and over again seeing and nothing happen. I sent
> 242
> patches out to subsystem maintainers on Monday and look at what's s
On Sat, Feb 10, 2007 at 10:58:58AM +0100, Heiko Carstens wrote:
> Alasdair, is dm already fixed or is there any chance that it will
> ever get fixed?
I still expect us to get this changed within the next few months. We've
dealt with the changes necessary to the crypt target for this. The final
p
Frederik Deweerdt wrote:
How about this one instead then:
Well, the warning you get is not that obvious:
test.c: In function 'main':
test.c:11: warning: 'deprecated_irqf' is deprecated
And as far as I could test (gcc 4.1.1 and gcc 3.4.3), Arjan's comment is
not true, the "static const int" don
On Saturday 10 February 2007 14:48, Alan wrote:
> > Well it's a technical issue -- it conflicts with the machine check
> > code that is already implemented by stealing away its events.
> > You would first need a CONFIG_MCE=n on x86-64 at least, otherwise
> > one of them will be unhappy.
>
> That i
> Well it's a technical issue -- it conflicts with the machine check
> code that is already implemented by stealing away its events.
> You would first need a CONFIG_MCE=n on x86-64 at least, otherwise
> one of them will be unhappy.
That is a fair point, albeit after far too long sitting stuck in t
On Sat, Feb 10, 2007 at 12:42:41PM +0100, Arnd Bergmann wrote:
> On Friday 09 February 2007 12:24, Arjan van de Ven wrote:
> >
> > On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote:
> > > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED;
> > > +static const int __deprecated SA_
Alan <[EMAIL PROTECTED]> writes:
> Please just push the EDAC K8 stuff. Andi will say "no" from now until the
> end of time, but end users want it, distributions want it, and Andi is
> not the EDAC maintainer so should consider himself overruled on what
> isn't a technical issue but a personal poli
David Woodhouse <[EMAIL PROTECTED]> writes:
> On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote:
> > lutimesat-simplify-utime2.patch
> > lutimesat-extend-do_utimes-with-flags.patch
> > lutimesat-actual-syscall-and-wire-up-on-i386.patch
> >
> > Do we want this? Ulrich says so. Will merge,
On Friday 09 February 2007 12:24, Arjan van de Ven wrote:
>
> On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote:
> > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED;
> > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM;
> > +static const int __deprecated SA
On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote:
> Which remembers me that I think that MIPS is using the non-compat version
> of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat
> syscall for some reason. Dunno.
It's OK as long as the 64-bit kernel, N32 and O32 u
On Fri, Feb 09, 2007 at 02:50:12PM -0800, Davide Libenzi wrote:
> On Fri, 9 Feb 2007, David Woodhouse wrote:
>
> > On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote:
> > > > I would strongly recommend that in the general case, you don't merge new
> > > > system calls unless the corresponding
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote:
> drivers-mdc-use-array_size-macro-when-appropriate.patch
> md-dm-reduce-stack-usage-with-stacked-block-devices.patch
>
> -> neilb
>
> (The second one is getting idiotic. When are we going to fix this??)
Since it was me who aske
> From: Russell King
> Newsgroups: gmane.linux.kernel
> Subject: Re: -mm merge plans for 2.6.21
> Date: Fri, 9 Feb 2007 22:03:27 +
[]
> However:
>
> sys_foo(int a, int c, unsigned long long b, unsigned long long d)
>
> is entirely reasonable and leaves us with sp
On Sat, 10 Feb 2007 02:15:11 +0100
Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Fri, 9 Feb 2007 19:37:53 +
> > Alan <[EMAIL PROTECTED]> wrote:
> >
> >> Please just push the EDAC K8 stuff.
> >
> > OK.
> >
> >> Andi will say "no" from now until the
> >> end
Andrew Morton wrote:
> On Fri, 9 Feb 2007 19:37:53 +
> Alan <[EMAIL PROTECTED]> wrote:
>
>> Please just push the EDAC K8 stuff.
>
> OK.
>
>> Andi will say "no" from now until the
>> end of time, but end users want it, distributions want it, and Andi is
>> not the EDAC maintainer so should co
On Fri, 9 Feb 2007, David Woodhouse wrote:
> On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote:
> > > I would strongly recommend that in the general case, you don't merge new
> > > system calls unless the corresponding compat_ system call is
> > > implemented.
> >
> > Good point.
>
> It's
On Fri, 2007-02-09 at 22:12 +, David Woodhouse wrote:
>
> We could _also_ do with a way to warn about unimplemented syscalls on
> any given architecture. I'm thinking about something along the lines
> of
> a kernel/syscalls.c containing nothing but...
>
> #include
>
> #ifnde
Andrew Morton a écrit :
factor-outstanding-i-o-error-handling.patch
factor-outstanding-i-o-error-handling-tidy.patch
I still like them. But the original problem is still present.
sync_sb_inodes-propagate-errors.patch
You explained in http://lkml.org/lkml/2007/1/2/238 that the mapping
On Fri, 2007-02-09 at 22:03 +, Russell King wrote:
> > Is that actually written anywhere, and does anyone bother to check?
>
> Mostly mailing list archives I'd guess. As far as anyone bothering
> to check, that's me when I'm aware of new syscalls... which typically
> happens a long time after
On Fri, Feb 09, 2007 at 02:00:49PM -0800, Andrew Morton wrote:
> +asmlinkage long sys_lio_submit(aio_context_t ctx_id, int mode, long nr,
> + struct iocb __user * __user *iocbpp, struct sigevent __user *event)
Not a problem. (r0 := ctx_id, r1 := mode, r2 := nr, r3 := iocbpp,
r4 := event) Tha
On Fri, Feb 09, 2007 at 09:53:19PM +, David Woodhouse wrote:
> On Fri, 2007-02-09 at 21:49 +, Russell King wrote:
> > urgh, new system calls... wonder if they fit in the ARM ABI... Looks
> > fine.
>
> Can you elucidate on _what_ you just checked for?
>
> There was something about alignme
On Fri, 9 Feb 2007 21:49:44 +
Russell King <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 09, 2007 at 01:45:16PM -0800, Andrew Morton wrote:
> > On Fri, 09 Feb 2007 17:35:35 +
> > David Woodhouse <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote:
> > >
On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote:
> > I would strongly recommend that in the general case, you don't merge new
> > system calls unless the corresponding compat_ system call is
> > implemented.
>
> Good point.
It's a _damn_ good point, but I see we went ahead and merged
sys_
On Fri, 9 Feb 2007 19:37:53 +
Alan <[EMAIL PROTECTED]> wrote:
> Please just push the EDAC K8 stuff.
OK.
> Andi will say "no" from now until the
> end of time, but end users want it, distributions want it, and Andi is
> not the EDAC maintainer so should consider himself overruled on what
> is
On Fri, 2007-02-09 at 21:49 +, Russell King wrote:
> urgh, new system calls... wonder if they fit in the ARM ABI... Looks
> fine.
Can you elucidate on _what_ you just checked for?
There was something about alignment of 64-bit arguments to syscalls
which affects MIPS and/or ARM which I can't
On Fri, Feb 09, 2007 at 01:45:16PM -0800, Andrew Morton wrote:
> On Fri, 09 Feb 2007 17:35:35 +
> David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote:
> > > lutimesat-simplify-utime2.patch
> > > lutimesat-extend-do_utimes-with-flags.patch
> >
On Fri, 09 Feb 2007 17:35:35 +
David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote:
> > lutimesat-simplify-utime2.patch
> > lutimesat-extend-do_utimes-with-flags.patch
> > lutimesat-actual-syscall-and-wire-up-on-i386.patch
> >
> > Do we want th
Please just push the EDAC K8 stuff. Andi will say "no" from now until the
end of time, but end users want it, distributions want it, and Andi is
not the EDAC maintainer so should consider himself overruled on what
isn't a technical issue but a personal political viewpoint.
Alan
-
To unsubscribe fr
On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote:
> lutimesat-simplify-utime2.patch
> lutimesat-extend-do_utimes-with-flags.patch
> lutimesat-actual-syscall-and-wire-up-on-i386.patch
>
> Do we want this? Ulrich says so. Will merge, I guess.
I would strongly recommend that in the general
On Thu, 2007-02-08 at 15:44 -0800, Andrew Morton wrote:
> Yeah, this seems to work.
>
> +#define emit_old_interrupt_name(old, new)\
> +static inline unsigned __deprecated emit_old_interrupt_name##old(void)
> \
> +{
Quoting Arjan van de Ven <[EMAIL PROTECTED]>:
>
> >
> > As long as nobody takes the address of them (which wouldn't compile today
> > anyway) then the compiler should be able to not allocate store for these.
> > That they're const might help too.
>
> are you really sure?
I've run some tests, and t
Andrew Morton wrote:
On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote:
Has it? I don't think I've ever observed any benefits from it and I don't
think anyone has ever got down and worked out what its drawbacks might be,
and seen if they can be demonstrated in practice.
On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Andrew Morton wrote:
> > sched-add-above-background-load-function.patch
> > mm-implement-swap-prefetching.patch
> > mm-implement-swap-prefetching-vs-zvc-stu
>
> As long as nobody takes the address of them (which wouldn't compile today
> anyway) then the compiler should be able to not allocate store for these.
> That they're const might help too.
are you really sure?
>
> > why not just bite the bullet?
> > removing version.h also broke the same all
On Feb 9 2007 14:04, Andi Kleen wrote:
>Andrew Morton <[EMAIL PROTECTED]> writes:
>>
>> As long as nobody takes the address of them (which wouldn't compile today
>> anyway) then the compiler should be able to not allocate store for these.
>
>This would only work for unit-at-a-time compilers (if
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> As long as nobody takes the address of them (which wouldn't compile today
> anyway) then the compiler should be able to not allocate store for these.
This would only work for unit-at-a-time compilers (if it works at all,
i'm not sure), but not older
On Fri, 09 Feb 2007 12:24:33 +0100 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote:
> > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED;
> > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM;
> > +static const
On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote:
> +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED;
> +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM;
> +static const int __deprecated SA_SHIRQ = IRQF_SHARED;
> +static const int __deprecated SA_PROBEIRQ =
On Fri, Feb 09, 2007 at 12:29:06AM +0100, Jan Engelhardt wrote:
>
> On Feb 8 2007 15:07, Andrew Morton wrote:
>
> >scheduled-removal-of-sa_xxx-interrupt-flags-fixups.patch
> >scheduled-removal-of-sa_xxx-interrupt-flags-fixups-2.patch
> >scheduled-removal-of-sa_xxx-interrupt-flags.patch
> >schedul
On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Andrew Morton wrote:
> > sched-add-above-background-load-function.patch
> > mm-implement-swap-prefetching.patch
> > mm-implement-swap-prefetching-vs-zvc-stuff.patch
> > mm-implement-swap-prefetching-vs-zvc-stu
On Fri, 9 Feb 2007 01:05:57 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 9 Feb 2007 09:26:11 +0100 Sébastien Dugué <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote:
> >
> > > Andrew,
> > >
> > > On 2/9/07, Andrew Morton <[E
Hello,
Andrew Morton wrote:
sched-add-above-background-load-function.patch
mm-implement-swap-prefetching.patch
mm-implement-swap-prefetching-vs-zvc-stuff.patch
mm-implement-swap-prefetching-vs-zvc-stuff-2.patch
mm-implement-swap-prefetching-use-ctl_unnumbered.patch
swap_prefetch-vs-zoned-counter
On Fri, 9 Feb 2007 09:26:11 +0100 Sébastien Dugué <[EMAIL PROTECTED]> wrote:
> On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote:
>
> > Andrew,
> >
> > On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.pa
On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.patch
> > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine-gfs2-fix.patch
> > fsaio
Andrew,
On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.patch
fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine-gfs2-fix.patch
fsaio-rename-__lock_page-to-lock_page_blocking.patch
fsaio-interfaces-to-initialize-and-to-test-a-w
On Thu, 8 Feb 2007 21:57:50 -0500 "Parag Warudkar" <[EMAIL PROTECTED]> wrote:
> >x86-fix-vdso-mapping-for-aout-executables.patch
> >a.out executables are presently non-functional. This patch needs more work.
>
> I have a patch for x86 ready and tested and I should be able to get
> the full thing
x86-fix-vdso-mapping-for-aout-executables.patch
a.out executables are presently non-functional. This patch needs more work.
I have a patch for x86 ready and tested and I should be able to get
the full thing (x86, ppc, sh and x86_64) out over the weekend. (This
time around I got rid of the CONFI
On Fri, 9 Feb 2007 11:55:40 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
>
> > Once a subsystem has a subsystem tree (git or quilt) I basically never
> > merge anything which belongs to that tree. It's always
> >
> > originator->mm->subsystemtree->Linus
> >
> > I
Andrew Morton writes:
> Once a subsystem has a subsystem tree (git or quilt) I basically never
> merge anything which belongs to that tree. It's always
>
> originator->mm->subsystemtree->Linus
>
> If the subsystem tree maintainer wants to tell me "I can't be bothered
> setting up a git pu
On Thu, 8 Feb 2007 18:34:49 -0500
Kyle McMartin <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote:
> > I'm getting fed up of holding onto hundreds of patches against subsystem
> > trees, sending them over and over again seeing and nothing happen. I sent
>
On Fri, 9 Feb 2007 00:29:06 +0100 (MET)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Feb 8 2007 15:07, Andrew Morton wrote:
>
> >scheduled-removal-of-sa_xxx-interrupt-flags-fixups.patch
> >scheduled-removal-of-sa_xxx-interrupt-flags-fixups-2.patch
> >scheduled-removal-of-sa_xxx-interrupt-fla
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote:
> I'm getting fed up of holding onto hundreds of patches against subsystem
> trees, sending them over and over again seeing and nothing happen. I sent 242
> patches out to subsystem maintainers on Monday and look at what's still here.
On Feb 8 2007 15:07, Andrew Morton wrote:
>scheduled-removal-of-sa_xxx-interrupt-flags-fixups.patch
>scheduled-removal-of-sa_xxx-interrupt-flags-fixups-2.patch
>scheduled-removal-of-sa_xxx-interrupt-flags.patch
>scheduled-removal-of-sa_xxx-interrupt-flags-ata-fix.patch
>
> This removes SA_INTERRU
> infiniband-work-around-gcc-bug-on-sparc64.patch
> ehca-fix-memleak-on-module-unloading.patch
> -> roland
Sorry, I misunderstood your email. I thought it was just a CC of
stuff you were already merging. I will handle these patches.
- R.
-
To unsubscribe from this list: send the line "uns
I'm getting fed up of holding onto hundreds of patches against subsystem
trees, sending them over and over again seeing and nothing happen. I sent 242
patches out to subsystem maintainers on Monday and look at what's still here.
rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch
uf
77 matches
Mail list logo