On Sat, Feb 23, 2008 at 7:19 AM, Rob Landley <[EMAIL PROTECTED]> wrote:
> On Friday 22 February 2008 08:17:44 you wrote:
> > On Tue, Jan 29, 2008 at 8:16 PM, Ralf Baechle <[EMAIL PROTECTED]> wrote:
> > > Known problem. The issue only hits when probing IRQs as the NE2000
> > > driver does.
compiling with
make CONFIG_DEBUG_SECTION_MISMATCH=y
I see the following warnings:
CC kernel/stacktrace.o
CC kernel/irq/handle.o
LD mm/built-in.o
WARNING: mm/built-in.o(.meminit.text+0x89e): Section mismatch in reference from
the function free_area_init_core() to the
On Fri, 22 Feb 2008 20:39:00 +0800 (CST) WANG Cong <[EMAIL PROTECTED]> wrote:
> From: Jeff Dike <[EMAIL PROTECTED]>
> Subject: Re: [PATCH 09/16] um: use get_personality()
> Date: Wed, 20 Feb 2008 11:27:34 -0500
> Message-ID: <[EMAIL PROTECTED]>
>
> > On Wed, Feb 20, 2008 at 07:19:13PM +0800,
On Fri, 2008-02-22 at 08:32 +0100, Jens Axboe wrote:
> On Thu, Feb 21 2008, Mike Galbraith wrote:
> > Greetings,
> >
> > K3b recently (9a4c854..5d9c4a7 pull) began terminally griping about
> > buffer underrun upon every attempt to burn a CD. I can't fully bisect
> > the problem because
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> could you try the fix below ontop of x86.git#testing, does it solve
> your boot hang?
find below another fix that is somewhat better as it does not affect the
native kernel and !PARAVIRT.
btw., this also explains why this bug wasnt reported sooner
On Fri, 2008-02-22 at 16:56 +0100, Rafael J. Wysocki wrote:
> On Friday, 22 of February 2008, Soeren Sonnenburg wrote:
> > On Fri, 2008-02-22 at 00:06 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, 21 of February 2008, Soeren Sonnenburg wrote:
> > > > On Thu, 2008-02-21 at 01:31 +0100, Rafael
On Fri, 2008-02-22 at 13:36 -0700, Peter W. Morreale wrote:
> On Fri, 2008-02-22 at 11:55 -0800, Sven-Thorsten Dietrich wrote:
> >
> > In high-contention, short-hold time situations, it may even make sense
> > to have multiple CPUs with multiple waiters spinning, depending on
> > hold-time vs.
On Tuesday 19 February 2008 19:14, Adrian Bunk wrote:
> This patch fixes a check-after-use spotted by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> 570462ca4441d8d63dfd46efe6e5b2b1c251a611 diff --git
> a/drivers/thermal/thermal.c b/drivers/thermal/thermal.c
Jeff Garzik wrote:
>> If this is the prefered driver these days, maybe it shouldn't be marked
>> experimental in the menu anymore?
>
> It's not marked experimental.
>
the comment on the very top of drivers/ata says:
tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
this is
On Fri, Feb 22, 2008 at 07:53:56PM -0800, Greg KH wrote:
> On Sat, Feb 23, 2008 at 04:41:15AM +0100, Sam Ravnborg wrote:
> > On Fri, Feb 22, 2008 at 04:53:49PM -0800, Greg KH wrote:
> > > On Fri, Feb 22, 2008 at 04:46:17PM -0800, Arjan van de Ven wrote:
> > > > On Fri, 22 Feb 2008 16:31:33 -0800
>
James,
could you try the fix below ontop of x86.git#testing, does it solve your
boot hang?
Ingo
--->
Subject: x86: stackprotector fix: do not zap %gs
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Sat Feb 23 07:06:55 CET 2008
pda_init() puts 0 into %gs - that's wrong because
Hi Thomas,
While reviewing CPU isolation patches Peter pointed out that instead of
changing arch specific irq handling I should be extending genirq code.
Which makes perfect sense. Why didn't I think of that before :)
Basically the idea is that by default isolated CPUs must not get HW
irqs routed
This just removes unused DEBUG_FORCEDAC define in the IOMMU code.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Cc: Richard Henderson <[EMAIL PROTECTED]>
Cc: Ivan Kokshaysky <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
---
arch/alpha/kernel/pci_iommu.c |1 -
1 files
This patch makes the IOMMU code not allocate a memory area spanning
LLD's segment boundary.
is_span_boundary() judges whether a memory area spans LLD's segment
boundary. If iommu_arena_find_pages() finds such a area, it tries to
find the next available memory area.
Signed-off-by: FUJITA Tomonori
This patch is preparation for modifications to fix the IOMMU segment
boundary problem.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Cc: Richard Henderson <[EMAIL PROTECTED]>
Cc: Ivan Kokshaysky <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
---
arch/alpha/kernel/pci_iommu.c |
This patchset is another sequel to my patchset to fix iommu segment
boundary problems, IOMMUs allocate memory areas without considering a
low level driver's segment boundary limits:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg11919.html
This patchset fixes the Alpha IOMMU code.
There are
iommu_arena_find_pages duplicates the code to access to the bitmap for
free space management. This patch convert the IOMMU code to have only
one place to access the bitmap, in the popular way that other IOMMUs
(e.g. POWER and SPARC) do.
This patch is preparation for modifications to fix the IOMMU
Drop the class/class_mask stuff; it's unnecessary
as long as the vendor and device IDs match.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
drivers/video/geode/gxfb_core.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/video/geode/gxfb_core.c
This one's from Jordan..
>From f29234fa3f3ece430c48227d0e2c0f0bcbff6e0f Mon Sep 17 00:00:00 2001
From: Jordan Crouse <[EMAIL PROTECTED]>
Date: Fri, 22 Feb 2008 19:48:40 -0500
Subject: [PATCH] gxfb: Set the right registers to tweak the sync polarity
While running in flatpanel mode it is important
This one's also from Jordan.
>From dea8d19f689706985b30be745ef1151082866374 Mon Sep 17 00:00:00 2001
From: Jordan Crouse <[EMAIL PROTECTED]>
Date: Fri, 22 Feb 2008 19:55:09 -0500
Subject: [PATCH] gxfb: Don't enable the CRT DACs when we are in flatpanel mode
When the FP strap is enabled, don't
Use a command line option (fbsize:) rather than hardcoding the vram size.
LxFB already does this; it's useful for machines that can't query the
BIOS for fb size. This patch originated from David Woodhouse, was
modified by Jordan Crouse, and was then modified further by me.
Signed-off-by: Andres
On Friday 22 February 2008, Alexey Zaytsev wrote:
> Well, it looks like Michael is not the bcm43xx maintaner. I sent the
> patch to him,
> because it was his code that broke the driver, and I thought it would
> be easy for him to review my patch, as it touches his code.
See? I'm tired of this
On Saturday 23 February 2008, Gordon Farquharson wrote:
> On Fri, Feb 22, 2008 at 7:07 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
> > > On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > >
> > > >
works for me!
applied.
thanks,
-len
ps. CONFIG_ACPI_CUSTOM_DSDT's only use is to guard the use of
CONFIG_ACPI_CUSTOM_DSDT_FILE:
#ifdef CONFIG_ACPI_CUSTOM_DSDT
#include CONFIG_ACPI_CUSTOM_DSDT_FILE
#endif
we could get rid of it if cpp could so something like
#if (CONFIG_ACPI_CUSTOM_DSDT_FILE
Daniel Barkalow wrote:
I find that the sequence of changes I make is pretty much unrelated to the
sequence of changes that end up in the project's history, because my
changes as I make them involve writing a lot of stubs (so I can build) and
then filling them out. It's beneficial to have
On 23-02-08 01:37, Chase Venters wrote:
Or perhaps you create a temporary topical branch for each thing you are
working on, and commit arbitrary changes then checkout another branch
when you need to change gears, finally --squashing the intermediate
commits when a particular piece of work is
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> Unfortunately, I missed your Bugzilla comment at
> http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28
Strange... But obviously you did see it eventually.
> Well, in the face of it, I'm considering to remove the code that
> acquires device
On Sat, Feb 23, 2008 at 10:07 AM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> > OK, please have a look at the modified patch below.
>
> All right, I'm fine with it. Now we just need to confirm that it works for
> people..
Looks good. Applied
On Fri, Feb 22, 2008 at 7:07 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
> > On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> >
> > > Option 1) is the worst of the three as that can cost
> > > of
On Sat, 2008-02-23 at 05:02 +0200, Boaz Harrosh wrote:
> On Sat, Feb 23, 2008 at 2:31 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > 2.6.24-stable review patch. If anyone has any objections, please let us
> > know.
> >
> > --
> > From: Boaz Harrosh <[EMAIL PROTECTED]>
> >
> >
On Fri, 22 Feb 2008, Chase Venters wrote:
> I've been making myself more familiar with git lately and I'm curious what
> habits others have adopted. (I know there are a few documents in circulation
> that deal with using git to work on the kernel but I don't think this has
> been specifically
On Sat, Feb 23, 2008 at 04:41:15AM +0100, Sam Ravnborg wrote:
> On Fri, Feb 22, 2008 at 04:53:49PM -0800, Greg KH wrote:
> > On Fri, Feb 22, 2008 at 04:46:17PM -0800, Arjan van de Ven wrote:
> > > On Fri, 22 Feb 2008 16:31:33 -0800
> > > Greg KH <[EMAIL PROTECTED]> wrote:
> > >
> > > >
On Sat, Feb 23, 2008 at 05:02:40AM +0200, Boaz Harrosh wrote:
> On Sat, Feb 23, 2008 at 2:31 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > 2.6.24-stable review patch. If anyone has any objections, please let us
> > know.
> >
> > --
> > From: Boaz Harrosh <[EMAIL PROTECTED]>
>
Quoting Nick Andrew ([EMAIL PROTECTED]):
> On Fri, Feb 22, 2008 at 04:14:12PM -0600, Serge E. Hallyn wrote:
> > Quoting Nick Andrew ([EMAIL PROTECTED]):
> > > config UTS_NS
> > > bool "UTS namespace"
> > > depends on NAMESPACES
> > > help
> > > - In this namespace tasks see different info
On Fri, Feb 22, 2008 at 04:53:49PM -0800, Greg KH wrote:
> On Fri, Feb 22, 2008 at 04:46:17PM -0800, Arjan van de Ven wrote:
> > On Fri, 22 Feb 2008 16:31:33 -0800
> > Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > > 2.6.24-stable review patch. If anyone has any objections, please let
> > > us know.
Matt Mackall wrote:
This is not quite what Peter and I were thinking of, I think. It's not
at all generic. How about a section that simply contains a set of
function pointers, a macro to add things to that section, and a function
that calls all the pointers in that section. Eg:
On Fri, Feb 22, 2008 at 12:23:15PM +, Toralf Förster wrote:
> Hello,
>
> the build with the attached .config failed, make ends with:
> ...
> CC arch/x86/lib/strstr_32.o
> CC arch/x86/lib/usercopy_32.o
> AR arch/x86/lib/lib.a
> LD vmlinux.o
> MODPOST vmlinux.o
>
On Sat, Feb 23, 2008 at 2:31 AM, Greg KH <[EMAIL PROTECTED]> wrote:
>
> 2.6.24-stable review patch. If anyone has any objections, please let us
> know.
>
> --
> From: Boaz Harrosh <[EMAIL PROTECTED]>
>
> commit: 61c92814dc324b541391757062ff02fbf3b08086
>
> The patch: "gdth:
> > > David, do you think writing 0 bytes is a valid use of this API?
> >
> > Just a zero byte transfer ... no, though it depends what you mean
> > by "valid". (I'm not sure I'd expect all controller drivers to
> > reject such requests.) That has no effect on bits-on-the-wire,
> > and would
Hi Andy,
Add 'type' attribute of the SDIO device to represent Standard Function
interface code in the human readable form.
these kind of things should not be part of the Linux kernel. A
userspace tool (call it lssdio if you want) should handle it.
Regards
Marcel
--
To unsubscribe from
On Fri, 2008-02-15 at 12:00 +0100, Thomas Petazzoni wrote:
> Hi,
>
> Le Mon, 11 Feb 2008 16:54:30 -0800,
> "H. Peter Anvin" <[EMAIL PROTECTED]> a écrit :
>
> > b) would be my first choice, and yes, it would be a good thing to
> > have a generalized mechanism for this. For the registrant, it's
On Friday 22 February 2008, Ned Forrester wrote:
>
> So, what I think you said is that it would be better for pxa2xx_spi to
> silently ignore a zero-length message, passing it back with the rest of
> the message when all is complete, than to reject the message.
Yes. Remember that the reason to
On 2008/2/23, Al Viro <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008 at 05:51:04PM -0800, Junio C Hamano wrote:
> > Al Viro <[EMAIL PROTECTED]> writes:
> >
> > > On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote:
> > >
> > >> >do you tend to clone the entire repository
'Lose' is when you don't win or you've lost something, and 'loose'
is when something isn't tight. I just want to tighten up the
spelling a bit regarding some loose comments.
Signed-off-by: Nick Andrew <[EMAIL PROTECTED]>
---
Yes, this is a digression.
Documentation/edac.txt
(sorry for the delay, travelling)
On Wed, 2008-02-20 at 14:57 +0100, Hans Rosenfeld wrote:
> The current code for /proc/pid/pagemap does not work with huge pages (on
> x86). The code will make no difference between a normal pmd and a huge
> page pmd, trying to parse the contents of the huge page
On Fri, Feb 22, 2008 at 05:51:04PM -0800, Junio C Hamano wrote:
> Al Viro <[EMAIL PROTECTED]> writes:
>
> > On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote:
> >
> >> >do you tend to clone the entire repository repeatedly into a series
> >> >of separate working directories
> >>
>
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> In the revised patch below I redefined the PM_EVENT_* things as flags so
> that I can "or" them and defined PM_EVENT_SLEEP in analogy with
> CONFIG_PM_SLEEP.
Ok, looks fine by me.
> > Didn't you miss the apci_pci_choose_state() thing that also
On Saturday, 23 of February 2008, Linus Torvalds wrote:
>
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > --- linux-2.6.orig/drivers/char/drm/i915_drv.c
> > +++ linux-2.6/drivers/char/drm/i915_drv.c
> > @@ -222,6 +222,7 @@ static void i915_restore_vga(struct drm_
> >
Al Viro <[EMAIL PROTECTED]> writes:
> On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote:
>
>> >do you tend to clone the entire repository repeatedly into a series
>> >of separate working directories
>>
>> Too time consuming on consumer drives with projects the size of Linux.
>
> git
On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote:
> >do you tend to clone the entire repository repeatedly into a series
> >of separate working directories
>
> Too time consuming on consumer drives with projects the size of Linux.
git clone -l -s
is not particulary slow...
--
To
On Feb 22 2008 18:37, Chase Venters wrote:
>
>I've been making myself more familiar with git lately and I'm curious what
>habits others have adopted. (I know there are a few documents in circulation
>that deal with using git to work on the kernel but I don't think this has
>been specifically
2008/2/23, Chase Venters <[EMAIL PROTECTED]> wrote:
>
> ... blablabla
>
> My question is: If you're working on multiple things at once, do you tend to
> clone the entire repository repeatedly into a series of separate working
> directories and do your work there, then pull that work (possibly
Clocksource and clockevent device based on the Atmel TC blocks.
The clockevent device handles both periodic and oneshot modes, so this
enables NO_HZ and high res timers on some platforms that previously
couldn't use those mechanisms.
This works on both AVR32 and AT91 chips, given relevant
Create based on and the
at91sam9263 and at32ap7000 datasheets. Most AT91 and AT32 SOCs have one
or two of these TC blocks, which include three 16-bit timers that can be
interconnected in various ways.
These TC blocks can be used for external interfacing (such as PWM and
measurement), or used
On Friday, 22 of February 2008, Alan Stern wrote:
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
>
> > BTW, below is a simplified version of the patch, without the mutex
> > protecting
> > suspending_task. I'd like to push it upstream if it looks good.
>
> It does look good. Go ahead and
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> I am eventually going to suggest cutting the backing filesystem entirely out
> of the picture,
You still need a database to manage the cache. A filesystem such as Ext3
makes a very handy database for four reasons:
(1) It exists and works.
(2) It
Add a defining fail/warn stubs for GPIO calls on platforms
that don't support the GPIO programming interface. That includes the
arch-specific implementation glue otherwise.
This facilitates a new model for GPIO usage: drivers that can use GPIOs
if they're available, but don't require them.
On Fri, Feb 22, 2008 at 04:14:12PM -0600, Serge E. Hallyn wrote:
> Quoting Nick Andrew ([EMAIL PROTECTED]):
> > config UTS_NS
> > bool "UTS namespace"
> > depends on NAMESPACES
> > help
> > - In this namespace tasks see different info provided with the
> > - uname() system
--- Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch makes the needlessly global smk_unlbl_ambient() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Casey Schaufler <[EMAIL PROTECTED]>
Oops.
>
> ---
> 60c7072cb922cdecdb8a4f08e5710c014e0e8a8c diff --git
>
On Fri, Feb 22, 2008 at 06:59:14PM -0500, Dave Jones wrote:
> On Fri, Feb 22, 2008 at 03:42:16PM -0800, Greg Kroah-Hartman wrote:
>
> > > > I thought that thread was for the much larger patches, not just this
> > > > Makefile change.
> > >
> > > At the least we'll likely want to also pick
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> --- linux-2.6.orig/drivers/char/drm/i915_drv.c
> +++ linux-2.6/drivers/char/drm/i915_drv.c
> @@ -222,6 +222,7 @@ static void i915_restore_vga(struct drm_
> dev_priv->saveGR[0x18]);
>
> /* Attribute controller
Group,
Currrently I do not subscribe to this mail alias, so please
keep the cc.
Currently a few calls exist where WAIT is specified (
(GFP_KERNEL)for the slab/slob allocators and also as an
additional argument, SLAB_PANIC is checked against
I've been making myself more familiar with git lately and I'm curious what
habits others have adopted. (I know there are a few documents in circulation
that deal with using git to work on the kernel but I don't think this has
been specifically covered).
My question is: If you're working on
e820_resource_resources could use insert_resource instead of request_resource
also move code_resource, data_resource, bss_resource, and crashk_res
out of e820_reserve_resources.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/e820_64.c
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Ulisses Furquim <[EMAIL PROTECTED]>
patch ac74c00e499ed276a965e5b5600667d5dc04a84a in mainline.
As the IN_ONESHOT bit is never set when an event is sent we must check it
in the watch's
Hitting either of the break statements in the while loop would cause
a double-unlock of info->lock.
[Jiri Slaby suggested simply returning is safe here, rather than a goto]
Noticed by sparse:
drivers/char/esp.c:2042:2: warning: context imbalance in 'rs_wait_until_sent' -
unexpected unlock
On Fri, Feb 22, 2008 at 04:46:17PM -0800, Arjan van de Ven wrote:
> On Fri, 22 Feb 2008 16:31:33 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > 2.6.24-stable review patch. If anyone has any objections, please let
> > us know.
>
>
> not ready for -stable yet. if ever for backporting
On Fri, 22 Feb 2008 16:31:33 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> 2.6.24-stable review patch. If anyone has any objections, please let
> us know.
not ready for -stable yet. if ever for backporting (doubtful)
>
> --
> From: Sam Ravnborg <[EMAIL PROTECTED]>
>
> commit:
On Friday 22 February 2008, Anton Vorontsov wrote:
> > +static inline int gpio_request(unsigned gpio, const char *label)
> > +{
> > + return -EINVAL;
>
> Could we return -ENOSYS instead, so drivers will able to distinguish
> between "something really failed" and "there is no gpio support,
>
Modify the help descriptions of usr/Kconfig for clarity, accuracy and
consistency.
This patch mostly clarifies what INITRAMFS_SOURCE does, i.e. optionally
build a CPIO archive of the initial root filesystem (initramfs) and
compress it and link it into the kernel. Note that usually the initramfs
On Fri, Feb 22, 2008 at 2:20 PM, Gregory Haskins
<[EMAIL PROTECTED]> wrote:
> Agreed, but it's still correct afaict. I added an extra might_sleep()
> to a path that really might sleep. I should have mentioned that in the
> header.
>
> In any case, its moot. Andi indicated this patch is
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Ingo Molnar <[EMAIL PROTECTED]>
(no matching git id as the upstream code is rewritten)
fix CPA cache attribute bug in v2.6.24. When phys_base is nonzero (when
CONFIG_RELOCATABLE=y) then
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Olaf Hering <[EMAIL PROTECTED]>
Commit: 092ca5bd61da6344f3b249754b337f2d48dfe08d
[POWERPC] Revert chrp_pci_fixup_vt8231_ata devinit to fix libata on pegasos
Commit
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Jay Vosburgh <[EMAIL PROTECTED]>
patch 4fe4763cd8cacd81d892193efb48b99c99c15323 in mainline.
Fix the "are we creating a duplicate" check to not compare
the name if the name is NULL
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Sam Ravnborg <[EMAIL PROTECTED]>
commit: e06b8b98da071f7dd78fb7822991694288047df0
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
===
I just read the excellent LWN writeup of the vmsplice
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Chuck Ebbert <[EMAIL PROTECTED]>
Commit: a1a98b72dbd17e53cd92b8e78f404525ebcfd981
Fix station address detection in smc
Megahertz EM1144 PCMCIA ethernet adapter needs special handling
because
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Oliver Neukum <[EMAIL PROTECTED]>
commit 1902869019918411c148c18cc3a22aade569ac9a upstream
if you fail in open() you must decrement the pm counter again.
Signed-off-by: Oliver Neukum <[EMAIL
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Boaz Harrosh <[EMAIL PROTECTED]>
commit: 61c92814dc324b541391757062ff02fbf3b08086
The patch: "gdth: switch to modern scsi host registration"
missed one simple fact when moving a way from
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Thomas Gleixner <[EMAIL PROTECTED]>
commit 89d694b9dbe769ca1004e01db0ca43964806a611
The default_disable() function was changed in commit:
76d2160147f43f982dfe881404cfde9fd0a9da21
genirq:
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Heiko Carstens <[EMAIL PROTECTED]>
commit: d5b02b3ff1d9a2e1074f559c84ed378cfa6fc3c0 upstream
Add missing exception table entry so that the kernel can handle
proctection exceptions as well on
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Thomas Gleixner <[EMAIL PROTECTED]>
commit: 5a7780e725d1bb4c3094fcc12f1c5c5faea1e988
Various user space callers ask for relative timeouts. While we fixed
that overflow issue in
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Thomas Gleixner <[EMAIL PROTECTED]>
commit 63070a79ba482c274bad10ac8c4b587a3e011f2c
A CLOCK_REALTIME timer, which has an absolute expiry time less than
the clock realtime offset calls with
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Oleg Nesterov <[EMAIL PROTECTED]>
commit 416529374b4793ba2d2e97e736d108a2e0f3ef07
Spotted by Pavel Emelyanov and Alexey Dobriyan.
compat_sys_nanosleep() implicitly uses
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Christoph Lameter <[EMAIL PROTECTED]>
patch 5bb983b0cce9b7b281af15730f7019116dd42568 in mainline.
gcc 4.2 spits out an annoying warning if one casts a const void *
pointer to a void *
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Oleg Nesterov <[EMAIL PROTECTED]>
commit 080344b98805553f9b01de0f59a41b1533036d8d
Spotted by Pavel Emelyanov and Alexey Dobriyan.
hrtimer_nanosleep() sets restart_block->arg1 = rmtp, but
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
patch 592a607bbc053bc6f614a0e619326009f4b3829e in mainline.
It appears that with the U3 northbridge, if the processor is in NAP
mode the whole time
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Jonathan Corbet <[EMAIL PROTECTED]>
patch 900cf086fd2fbad07f72f4575449e0d0958f860f in mainline.
So I spent a while pounding my head against my monitor trying to figure
out the vmsplice()
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 406a1d868001423c85a3165288e566e65f424fe6
The recent UDP patch exposed this bug in the audit code. It
was calling pskb_expand_head without increasing skb->truesize.
The caller of
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 29ffe1a5c52dae13b6efead97aab9b058f38fce4
When ip_fragment has to hit the slow path the value of skb->truesize
may go out of sync because we would have updated it without changing
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: b6c0632105f7d7548f1d642ba830088478d4f2b0
The bluetooth hci_conn sysfs add/del executed in the default
workqueue. If the del_conn is executed after the new add_conn with
same
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 2614fa59fa805cd488083c5602eb48533cdbc018
When I moved the nexthdr setting out of IPComp I accidently moved
the reading of ipch->nexthdr after the decompression. Unfortunately
this
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 8cf8e5a67fb07f583aac94482ba51a7930dab493
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=9825
The inet_diag_lock_handler function uses ERR_PTR to encode errors but
its callers
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: b1641064a3f4a58644bc2e8edf40c025c58473b4
I made a silly typo by entering IPPROTO_IP (== 0) instead of
IPPROTO_IPIP (== 4). This broke the reception of incompressible
packets.
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: dded91611a728d65721cdab3dd41d801a356fa15
if_addrlabel.h is needed for iproute2 usage.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 936f6f8e1bc46834bbb3e3fa3ac13ab44f1e7ba6
Update fib_trie with some fib_hash fixes:
- check for duplicate alternative routes for prefix+tos+priority when
replacing route
-
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: c18865f39276435abb9286f9a816cb5b66c99a00
fib_info can be shared by many route prefixes but we don't want
duplicate alternative routes for a prefix+tos+priority. Last change
was not
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: e1770d97a730ff4c3aa1775d98f4d0558390607f
As pointed out by Adrian Bunk, commit
45c950e0f839fded922ebc0bfd59b1081cc71b70 ("fix memory leak in netlabel
code") caused a double-free
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 268bcca1e7b0d244afd07ea89cda672e61b0fc4a
Setting up a meta match causes a kernel OOPS because of uninitialized
elements in tree.
[ 37.322381] BUG: unable to handle kernel NULL
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 04f217aca4d803fe72c2c54fe460d68f5233ce52
If userspace passes a unknown match index into em_meta, then
em_meta_change will return an error and the data for the match will
not be
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 16ca3f913001efdb6171a2781ef41c77474e3895
In strategy_allowed_congestion_control of the 2.6.24 kernel, when
sysctl_string return 1 on success,it should call
1 - 100 of 1123 matches
Mail list logo
