uergen Gross writes:
>
>> Mails to chr...@sous-sol.org are not deliverable since several months.
>> Drop him as PARAVIRT_OPS maintainer.
>>
>> Signed-off-by: Juergen Gross
Acked-by: Chris Wright
;)
thanks,
-chris
>> ---
>> MAINTAINERS | 1 -
>>
* Guenter Roeck (li...@roeck-us.net) wrote:
> On Thu, Jul 11, 2013 at 12:00:54PM -0700, Chris Wright wrote:
> > * Guenter Roeck (li...@roeck-us.net) wrote:
> > > On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > > > One thing I've seen is the BIO
* Guenter Roeck (li...@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > One thing I've seen is the BIOS zeroing the base register address when
> > VT-d is disabled in BIOS. So, Guenter, a "fix" may be simply enabling
> >
* Guenter Roeck (li...@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > * Guenter Roeck (li...@roeck-us.net) wrote:
> > > On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > > > [+cc Joerg, David, iommu list]
* Guenter Roeck (li...@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > [+cc Joerg, David, iommu list]
> >
> > On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck wrote:
> > > I started seeing this problem after updating the BIOS trying fix another
> > > issue,
It's only used locally, no need to pollute global namespace.
Signed-off-by: Chris Wright
---
fs/debugfs/inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 4733eab..2c9fafb 100644
--- a/fs/debugfs/inode.c
+++
* Oliver Pinter ([EMAIL PROTECTED]) wrote:
> mainline: ecaf18c15aac8bb9bed7b7aa0e382fe252e275d5
>
> --->8---
> commit ecaf18c15aac8bb9bed7b7aa0e382fe252e275d5
> Author: Eric Paris <[EMAIL PROTECTED]>
> Date: Tue Dec 4 23:45:31 2007 -0800
>
> VM/Security: add security hook to do_brk
>
>
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> lookup_address() receives two parameters, but efi_64.c call
> is passing only one. It's actually preventing the tree from compiling
>
> Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Good catch, I know I don't test with CONFIG
Refactor ioport unification to pull out common code.
Cc: [EMAIL PROTECTED]
Cc: Kevin Winchester <[EMAIL PROTECTED]>
Cc: Zach Brown <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PR
on top of Miguel's (can respin to standalone if that's better).
Tested (on both 32 and 64-bit) with simple:
#include
#include
main()
{
if (iopl(3) == 0)
asm ("cli\nsti\n"::);
}
thanks,
-chris
--
From: Chris Wright <[EMAIL PROTECTED]>
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> On Thu, 3 Jan 2008, Chris Wright wrote:
> > Yes, paravirt ops have a well-specified calling convention (register
> > based). There was a cleanup that Andi did that caused the problem
> > because it removed all the "f
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> Hmm, I know paravirt-ops had an issue with mcount in the RT tree. I can't
> remember the exact issues, but it did have something to do with the way
> parameters were passed in.
>
> Chris, do you remember what the issues were?
Yes, paravirt ops have a
> forked from a parent created when audit was enabled to not take the fastest
> syscall path thru entry.S
>
> Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Yeah, I think that's the right thing to do. Doesn't have an
audit_context anyway.
Acked-by: Chris Wright
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> Do other people want to stand up and be "LSM maintainers" in the sense
> that they also end up being informed members who can also stand up for new
> modules and help merge them, rather than just push the existing one(s)?
> Chris? Casey? Crispin?
St
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.
I agree th
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > Yes, and I think we can still improve performance although I can't see
> > anyway to help out the modular case, so I guess it will have to incur
> > the hit that's always been there.
>
* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
> On Oct 22 2007 22:16, Chris Wright wrote:
> >Yes, and I think we can still improve performance although I can't see
> >anyway to help out the modular case, so I guess it will have to incur
> >the hit that's always be
* Arjan van de Ven ([EMAIL PROTECTED]) wrote:
> On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
> James Morris <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> >
> > > >I'd like to note that I asked people who were actually affected,
> > > >and had examples of their real-wor
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> Quoting Chris Wright ([EMAIL PROTECTED]):
> > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> > > I guess now that I've written this out, it seems pretty clear
> > > that capget64() and capget64() are the way to go.
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> I guess now that I've written this out, it seems pretty clear
> that capget64() and capget64() are the way to go. Any objections?
How is capget64() different from capget() that supports 2 different
header->versions (I thought that was the whole point
* Oliver Pinter ([EMAIL PROTECTED]) wrote:
> it is Lepton's patch.
> Namesys boys, this patch is OK?
> Greg, I neither do find this patch in Linus's tree.
The point is, if it's not important enough to go into Linus' tree, than
it isn't important enough to be in the -stable tree. So please get thi
diff --git a/Makefile b/Makefile
index 3067f6a..12edea0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 22
-EXTRAVERSION = .6
+EXTRAVERSION = .7
NAME = Holy Dancing Manatees, Batman!
# *DOCUMENTATION*
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch
tions(+), 8 deletions(-)
Summary of changes from v2.6.22.6 to v2.6.22.7
==
Andi Kleen (1):
x86_64: Zero extend all registers after ptrace in 32bit entry path.
Chris Wright (1):
Linux 2.6.22.7
-
To unsubscribe from this list: send the
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
> Ok, so I need to get a new CPU like the Intel Core Duo that has VT
> features? I have an old Pentium 4 at the moment, without any VT features.
Depends on your goals. You can certainly give a paravirt Xen guest[1]
physical hardware without any V
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
> If one could directly expose a device to the guest, this feature could
> be extremely useful for me.
> Is it possible? How would it manage to handle the DMA bus mastering?
Yes it's possible (Xen supports pci pass through). Without an IOMMU
(lik
* Dave Jones ([EMAIL PROTECTED]) wrote:
> I have a reservation about voting for any of the above.
> Normally during any process involving votes, there exists some sort
> of "why you should vote for me" type statement. Does such a thing
> exist for this process ?
Last year each nominee made a stat
tree should be
working fine right now with d34fda4a84c18402640a1a2342d6e6d9829e6db7
committed, and can be further refined with the patch below that's just
waiting on some further testing.
thanks,
-chris
--
Subject: [PATCH] x86: skip paravirt patching when appropriate
From: Chris Wright &
* Chris Wright ([EMAIL PROTECTED]) wrote:
> Now that I understand the problem, I do have a very simple (slightly
> overkill) fix for paravirt patching. This can be cleaned up to avoid
> the copies when they aren't needed, but that will take a little more
> auditing of the vari
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Sat, 18 Aug 2007, Chris Wright wrote:
> > >
> > > Check the latest git head. Does it still break?
> >
> > Yeah, this is the latest git. The broken commit is Rusty's patch which,
> > after Linus rever
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> > This patch breaks Xen booting.
>
> Check the latest git head. Does it still break?
Yeah, this is the latest git. The broken commit is Rusty's patch which,
after Linus reverted the write-protected remap changes, is no longer
necessary. AFAICT patchin
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> This patch breaks Xen booting. I get infinite recursive faults during
> patching when this patch is present. If I boot with
> "noreplace-paravirt" it works OK, and it works as expected if I back
> this patch out. I haven't tracked down the exact
* Jeff Dike ([EMAIL PROTECTED]) wrote:
> [ This is both 2.6.24 and -stable material ]
>
> SuSE seems to require that binaries have a .note.SuSE section.
> Without it, UML segfaults if any parameters are passed on the command
> line.
Huh!? Why do we need a SuSE section?
thanks,
-chris
-
To unsubs
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> On 08/03, Chris Wright wrote:
> >
> > +long do_restart_poll(struct restart_block *restart_block)
> > +{
> > + struct pollfd __user *ufds = (struct pollfd __user*)restart_block->arg0;
> > + int nfds = restart_bloc
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> Only caveat, is that it has to be done before smp gets in the game, and
> with interrupts disabled. (which makes the function in vsmp.c not eligible).
>
> My current option is to force VSMP to use PARAVIRT, as said before, and
> then fill
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> As alternatives what we have now, we can either keep the paravirt_ops as
> it is now for the native case, just hooking the vsmp functions in place
> of the normal one, (there are just three ops anyway), refill the
> paravirt_ops entirely i
* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> On Mon, 13 Aug 2007 11:55:36 -0700 Chris Wright wrote:
> > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > > +F: arch/i386/xen/
> > > +F: drivers/*/xen-*front.c
> > > +F: drivers/xen/
> >
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e4e1cc3..8395aba 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5153,6 +5153,11 @@ M: [EMAIL PROTEC
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2166416..44768ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3519,6 +3519,9 @@ M: [EMAIL PROTEC
s,
-chris
--
Subject: [PATCH] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal
From: Chris Wright <[EMAIL PROTECTED]>
Lomesh reported poll returning EINTR during suspend/resume cycle.
This is caused by the STOP/CONT cycle that the freezer uses, generating
a pending signal for what
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> > I am not sure. This means we restart sys_poll() with the same timeout
> > if there is no pending signal. I think we need ERESTART_RESTARTBLOCK
> > logic.
>
> Forgot to mention, sys_select() can use ERESTARTNOHAND because it
> modifies "struct timeval
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Mon, 30 Jul 2007, Chris Wright wrote:
> > This also fixes paravirt patching which was broken when text_poke()
> > tried to patch the various pv ops in lookup_address.
>
> Hmm. What is "this"? The revert?
Yes
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
> > On my Turion64-based HPC nx6325 with the 2.6.23-rc1 x86_64 kernel doing
> >
> > # echo 0 > /sys/devices/system/cpu/cpu1/online
> >
> > causes the system to crash in a spectacular fashion (call traces g
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Sun, 29 Jul 2007 19:05:05 +0200 Manfred Spraul <[EMAIL PROTECTED]> wrote:
> > poll() returns -EINTR if a signal is pending.
> > EINTR is a bad choice: it means that poll returns to user space if the
> > task is stopped by SIGSTOP/SIGCONT or by the fre
* Manfred Spraul ([EMAIL PROTECTED]) wrote:
> poll() returns -EINTR if a signal is pending.
> EINTR is a bad choice: it means that poll returns to user space if the
> task is stopped by SIGSTOP/SIGCONT or by the freezer.
> select() and ppoll() both use ERESTARTNOHAND, this avoids a return to
> user
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> I believe there's still a lot that can be merged, and I'm responsible
> for some of it. Parts of suspend code should be shared, yet they are
> in differently named files in differently named directories.
>
> Ok, I guess I should fix it, arch/x86 or not.
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> Can we see some stats on:
>
> How many files were auto-merged?
> How many files got 32.c and 64.c extensions?
> How many existed only in one arch?
It's mostly about file movement first.
Kbuild |8 +-
Mak
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> This patch provides a new set of functions for managing the descriptor
> tables that can be used instead of putting the raw assembly in .c files.
Looks alright, some cleanups below
> Remodeling of store_tr() suggested by Frederik Deweerdt.
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Thu, 2007-07-19 at 09:27 +1000, Rusty Russell wrote:
> > On Wed, 2007-07-18 at 09:19 -0700, Zachary Amsden wrote:
> > > > +#define GET_CONTENTS(desc) (((desc)->raw32.b >> 10) & 3)
> > > > +#define GET_WRITABLE(desc) (((desc)->raw32.b >> 9) &
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> Remove i386's Xgt_desc_struct definition and use desc_def.h's desc_ptr.
plus this is needed now
Index: linus-2.6/drivers/lguest/lg.h
===
--- linus-2.6.orig/drivers/lguest/lg.h
+++ linus-2
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> Actually, given that when lsm was being introduced, lsm seemed to
> improve performance overall, have you taken any measurements to show
> that this is actually the case? Of course it makes sense that it would,
> but witjout measurements we do not kno
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> Sorry, but I can't be bothered splitting it up. Greg, Chris: please just
> apply the bits which apply and drop the other bits if that's OK.
Yup
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> In that case, it's almost certainly that that tree isn't doing the proper
> "git update-server-info" when people push to it.
Yup, should be fixed now.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
* Nish Aravamudan ([EMAIL PROTECTED]) wrote:
> On 7/12/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > That is a tree that Chris did, and I didn't realize we were maintaining
> > it as the "official" stable tree, that is why it is not mentioned in the
> > release notes :)
>
> Fair enough -- it's just a
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> Ok by me, although I suspect a lot of the cases where the hpet one
> was needed got resolved with the PCI HPET resource fix But it's still
> safer to check.
>
> However I don't think patches should go into stable before they
> hit Linus' tree.
Agreed, we
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> Andrew,
>
> On Wed, 2007-07-11 at 16:57 -0700, Andrew Morton wrote:
> > They all look pretty innocuous to me.
> >
> > Could you please take a second look, decide if any of them should also be
> > in 2.6.22.x and let me know?
>
> i386-hpet-check-if-t
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> The equivalent to the powerpc way would be essentially to report i386
> into the x86-64 code base and leave the really old hardware only
> in arch/i386. I've considered doing it, but it would be an awful
> lot of work and to tempt distributions to actually
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> The HPET change, which is the larger part of the conversion set simply
> because we now share the code with i386, might be split out by disabling
> HPET in the first step, doing the PIT / APIC conversion and then the
> HPET one in a separate step.
The
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> For example, we can make sure that the code in question that actually
> touches the hardware stays exactly the same, and then just move the
> interfaces around - and basically guarantee that _zero_ hardware-specific
> issues pop up when you switch ov
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Andrew - how do you feel about keeping this in the -mm tree until Linus,
> Andi, Ingo, and Thomas get on the same page (which may be around the 2.6.24
> merge window, by my guesstimate)?
Well, that's supposed to be Andi's tree and aggregated by Andr
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
> (Note - I'm just a usually-confused crash test dummy here...)
>
> > Well I spent a lot of time making the x86-64 timing code work
> > well on a variety of machines; working around a wide variety
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> > If that isn't possible it needs very careful review which just hasn't
> > happened yet. But I'm not convinced even step by step is not possible
> > here.
>
> There is no step by step thing. You convert an arch to clock events or
> you convert it not
> +static inline void bprm_clear_caps(struct linux_binprm *bprm)
> +{
> + cap_clear (bprm->cap_inheritable);
> + cap_clear (bprm->cap_permitted);
> + cap_clear (bprm->cap_effective);
While there, can you clean that bit up a touch?
cap_clear(bprm->cap_inheritable);
cap_
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Zachary Amsden wrote:
> >I'd rather keep it, even with bitrot - it was non-trivial to get
> >correct, and found many surprises in the code; most notably, it can
> >detect
> >
> >1) PTE writes to pages not declared as page tables
> >2) Failure to
t (already has !CONFIG_NEED_MULTIPLE_NODES dependency,
dunno if VMI has the same limitation). It definitely should not have
a misleading Kconfig name. I'd nuke it all rather than #if 0.
thanks,
-chris
--
Subject: [PATCH] VMI: remove CONFIG_DEBUG_PAGE_TYPE and associated bitrotted
code
Fro
* Uli Luckas ([EMAIL PROTECTED]) wrote:
> On Tuesday, 3. July 2007, Chuck Ebbert wrote:
> > On 07/03/2007 03:28 PM, Chris Friesen wrote:
> > > Arne Georg Gleditsch wrote:
> > >> An interesting exercise might be to
> > >> code up a small program to call adjtimex with timex.status |= STA_INS,
> > >>
* Hawk Xu ([EMAIL PROTECTED]) wrote:
> Add hook inode_post_removexattr for updating inode security field after
> successful removexattr operation.
That is an insufficient explanation of why it's needed, who is using it,
etc.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscr
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> and simple LSMs that can be
> unloaded safely can permit it.
there are none, and making the above possible is prohibitively
expensive.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> Sigh, as much as I would *like* to stay out of this (I don't
> use modules at all on any system where I can avoid it), won't
> it make development - and especially testing - of new lsms
> much more painful and therefore less likely?
Dev, hopefully not
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> Just hoping to avoid a change collision. If I have to deal
> with this today it's easy, if it doesn't show up anywhere
> until 2.6.28 I'm breezing, but if it all hits in two weeks I
> have some scrambling and yet another delay to deal with. Not
> your
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> So, for planning purposes, when ought I expect to have to start
> dealing with this?
What is your specific concern or use case?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
* James Morris ([EMAIL PROTECTED]) wrote:
> On Sun, 24 Jun 2007, Chris Wright wrote:
>
> > * James Morris ([EMAIL PROTECTED]) wrote:
> > > -module_param_named(disable, capability_disable, int, 0);
> > > -MODULE_PARM_DESC(disable, "To disable capabil
* James Morris ([EMAIL PROTECTED]) wrote:
> -module_param_named(disable, capability_disable, int, 0);
> -MODULE_PARM_DESC(disable, "To disable capabilities module set disable = 1");
> +
> +static int __init capability_disable_setup(char *str)
> +{
> + capability_disable = simple_strtol(str, NUL
* Chris Mason ([EMAIL PROTECTED]) wrote:
> I'm sure people there will have a different versions of events. The
> one part that was discussed was if pathname based security was
> useful, and a number of the people in the room (outside of
> novell) said it was. Now, it could be that nobody wanted
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> Chris, thanks a hell of a lot for looking into this!!!
>
> -rt doesn't do much with paravirt, but since both -rt and lguest are two
> things I love to play with, it was really bothering me that they were
> not getting along.
It was bugging me too, now
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> * Chris Wright <[EMAIL PROTECTED]> wrote:
> > Current -rt is broken when compiling with CONFIG_PARAVIRT and
> > CONFIG_MCOUNT both enabled. Because CONFIG_MCOUNT disables
> > CONFIG_REGPARM, the calling convention must once
debugging.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
Patch against patch-2.6.21.5-rt17
arch/i386/kernel/paravirt.c | 98 ++--
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/para
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Jay Vosburgh wrote:
> > The following patch (based on a patch from Stephen Hemminger
> ><[EMAIL PROTECTED]>) removes use after free conditions in
> >the unregister path for the bonding master. Without this patch, an
> >operation of the form "echo -bon
* Stefan Richter ([EMAIL PROTECTED]) wrote:
> + Other kernel trees can be found listed at http://kernel.org/git and in
Should be http://git.kernel.org/ these days
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
* Nish Aravamudan ([EMAIL PROTECTED]) wrote:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=summary
> shows 2.6.21.1 as the last 2.6.21.Y release. Is that intentional?
Updated, thanks.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
* Stephane Eranian ([EMAIL PROTECTED]) wrote:
> * allocate_msrs() allocates two tables per CPU. One for the
>counters, the other for the eventsel registers. But then
>nmi_setup() copies the cpu_msrs[0] into cpu_msrs[] of all
>other cpus. This operation overrides the cpu_msrs[].counters
* Chris Rankin ([EMAIL PROTECTED]) wrote:
> Shouldn't this patch from Tejun be applied to 2.6.21.x as well as 2.6.20.x?
>
> Tejun Heo (2):
> ...
> driver-core: don't free devt_attr till the device is released
It is in both.
thanks,
-chris
-
To unsubscribe from this list: send the lin
* Pallipadi, Venkatesh ([EMAIL PROTECTED]) wrote:
> > * Thomas Gleixner (mailto:[EMAIL PROTECTED]) wrote:
> > I fixed this against -mm already. I don't think that it is relevant for
> > stable. The issue was found with Venkis hpet force enable patches on a
> > ICH4 system. I doubt that any of thos
A. Steinberg <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
[chrisw: rebase against Len's changes in -mm]
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
drivers/acpi/processor_idle.c |9 +
1 file changed, 5 insertions(+), 4 deletions
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> The PC-speaker code has a quite creative method to serialize access to
> the PIT: It uses a local lock.
>
> On i386 and x86_64 the access to the PIT is serialized by a lock in the
> architecture code. The separate locking in the PC-speaker code ignore
* Paul Albrecht ([EMAIL PROTECTED]) wrote:
> Yes, i8042.noaux works. Here's the dmesg output:
>
> Linux version 2.6.21.4 ([EMAIL PROTECTED]) (gcc version 3.3.3) #1
Does 2.6.21.5 work w/out noaux on command line?
thanks
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
olreg
Auke Kok (1):
e1000: disable polling before registering netdevice
Björn Steinbrink (1):
timer statistics: fix race
Chris Wright (2):
x86: fix oprofile double free
Linux 2.6.21.5
Daniel Drake (2):
ALSA: usb-audio: explicitly match Logitech QuickCam
zd1211rw
diff --git a/Makefile b/Makefile
index a87a7d1..710c004 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 20
-EXTRAVERSION = .13
+EXTRAVERSION = .14
NAME = Homicidal Dwarf Hamster
# *DOCUMENTATION*
diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/m
: fix mod_timer() interval
ntfs_init_locked_inode(): fix array indexing
Andy Green (1):
kbuild: fixdep segfault on pathological string-o-death
Chris Wright (1):
Linux 2.6.20.14
Dan Williams (1):
iop13xx: fix i/o address translation
Daniel Drake (1):
ALSA: usb-
* Chris Wright ([EMAIL PROTECTED]) wrote:
> Roll-up patch available at:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.21.5-rc1.{gz,bz2}
Roll-up updated to fix broken aacraid patch:
http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch
* Greg KH ([EMAIL PROTECTED]) wrote:
> On Fri, Jun 08, 2007 at 10:47:29AM -0700, Chris Wright wrote:
> > * Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> > > Maybe a mailing list for stable-commits could be added, like mm-commits?
> >
> > I was thinking the same thing.
liver platform function
pointer. The enclosed patch, unmodified as tested by Rainer, solves the
problem.
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
[chrisw: backport to 2.6.2
* Salyzyn, Mark ([EMAIL PROTECTED]) wrote:
> Yes, split the patch into the two pieces for 2.6.21.1/2.6.21.4
Sorry, didn't parse. Are you suggesting to use the patch I included
(which simply drops the ->adapter_restart init), or the original patch
plus Mark Havercamp's patch to add ->adapter_resta
* Theodore Tso ([EMAIL PROTECTED]) wrote:
> If this doesn't fix a user-visiable bug, should we be including it in
> the stable patch series? (Assuming that it doesn't, I wouldn't, but I
> tend to be more conservative about what I would include in a stable
> production release.)
Rolf, despite simp
* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> Maybe a mailing list for stable-commits could be added, like mm-commits?
I was thinking the same thing.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
the
problem.
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
[chrisw: backport to 2.6.21.4]
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/aacraid
* Chris Wright ([EMAIL PROTECTED]) wrote:
> Roll-up patch available at:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.14-rc1.{gz,bz2}
Roll-up updated to fix broken patch.
http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.
s.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
[chrisw: backport to 2.6.20]
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/core/dev.c | 10 ++
net/core/net-sysfs.c |8 +++-
2 files chan
* Fortier,Vincent [Montreal] ([EMAIL PROTECTED]) wrote:
> I have encoutered a bug using fixdep when compiling the Apani VPN
> contivity client v3.3 (v3.5 seems fine). The bug started happening with
> the release of the 2948 build of FC6 kernel (corresponding to a post
> 2.6.20.7) and caused fixdep
PROTECTED]>
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
X-Git-Url:
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinu
til we found the root cause of that problem.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/time/tick-sched
1 - 100 of 982 matches
Mail list logo
