From: Josh Boyer
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Dave Jones
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: John Stultz
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On Wednesday, August 15, 2012, Huang Ying wrote:
> This patch fixes the following bug:
>
> http://marc.info/?l=linux-pci=134338059022620=2
>
> Where lspci does not work properly if a device and the corresponding
> parent bridge (such as PCIe port) is suspended. This is because the
> device
From: Matt Mackall
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On Wed, Aug 15, 2012 at 06:52:06AM -0400, Neil Horman wrote:
> On Tue, Aug 14, 2012 at 03:34:24PM -0700, John Fastabend wrote:
> > Add lock to prevent a race with a file closing and also remove
> > useless and ugly sscanf code. The extra code was never needed
> > and the case it supposedly
From: Kees Cook
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Alan Stern
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: "H. Peter Anvin"
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On 08/04/2012 11:24 AM, Geert Uytterhoeven wrote:
> Below is the list of build error/warning regressions/improvements in
> v3.6-rc1[1] compared to v3.5[2].
...
> + drivers/i2c/busses/i2c-designware-core.c: error: 'KBUILD_MODNAME'
> undeclared (first use in this function):
This is a real
From: "H. Peter Anvin"
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: "H. Peter Anvin"
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Linus Torvalds
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: sordna
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Sam Ravnborg
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Andrew Worsley
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On Tue, Aug 14, 2012 at 06:23:58PM -0500, Ashley Lai wrote:
> Change log V3:
> - Replaced TPM_NO_EVENT_LOG macro with stubs
> - Removed tpm_noeventlog.c file
> - Called of_node_put() before return in tpm_of.c
>
> Change log V2:
> - Removed unnecessary tpm_bios_log_setup and tpm_bios_log_teardown
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
The "driver" struct for a gadget driver is named *_driver. On module
load, the gadget expects a UDC driver to be loaded and avaiable. If this
is not the case => -ENODEV and bye bye. That means that the gadget
driver is initialized immediately. The initialization process includes
calling ->bind()
On Wed, 2012-08-15 at 22:22 +0300, Michael S. Tsirkin wrote:
> On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote:
> > On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote:
> > > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote:
> > > > v8:
> > > >
> > > >
On Wed, 2012-08-15 at 17:14 +0200, Peter Zijlstra wrote:
> Other than that I'm not entirely happy with the growing #ifdef maze.
> Granted this new one isn't nearly as bad as some of the existing ones,
> but I do wish someone would clean up some of that.
To get rid of the #ifdefs, just make the
From: "H. Peter Anvin"
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: NeilBrown
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On Wednesday, August 15, 2012, Bjorn Helgaas wrote:
> On Thu, May 24, 2012 at 2:45 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > We want to report that the kernel supports ASPM to the BIOS even if
> > the BIOS signals us that it doesn't. So, we need the flags to include
> >
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathieu Desnoyers
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Tony Luck
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Johannes Berg
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mark Brown
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Tony Luck
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mark Brown
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mauro Carvalho Chehab
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: John Stultz
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On Wednesday, August 15, 2012, Hans de Goede wrote:
> Hi,
>
> On 08/15/2012 07:13 AM, Miklos Szeredi wrote:
> > Suspend oopses in generic_ide_suspend() because dev_get_drvdata()
> > returns NULL (dev->p->driver_data == NULL) and this function is not
> > prepared for this.
> >
> > I bisected it to
From: Linus Torvalds
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On 15 August 2012 20:03, Olof Johansson wrote:
> On Wed, Aug 15, 2012 at 06:37:11PM +0100, Catalin Marinas wrote:
>> If we add machine_desc structure back, we could print which machine was
>> matched. But so far I try to keep the SoC code to a minimum and just do
>> the probing later in the SoC
From: Thomas Gleixner
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
Sorry, just trivial typos:
On Wed, Aug 15, 2012 at 05:48:14PM +0200, Miklos Szeredi wrote:
> +Directories
> +---
> +
> +Overlaying mainly involved directories. If a given name appears in both
s/involved/involves/.
> +Non-standard behavior
> +-
> +
> +The copy_up
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: "Luck, Tony"
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: wangyanqing
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Thomas Gleixner
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Thomas Gleixner
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Artur Zimmer
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Trond Myklebust
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Florian Echtler
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Theodore Ts'o
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mauro Carvalho Chehab
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Peter Stuge
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Denis Pershin
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: James Bottomley
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Michał Sroczyński
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Marek Vasut
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Andrew Vasquez
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Sonny Rao
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: NeilBrown
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Ian Campbell
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Daniel Schwierzeck
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Avi Kivity
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Jeff Layton
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On Thu, May 24, 2012 at 2:45 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> We want to report that the kernel supports ASPM to the BIOS even if
> the BIOS signals us that it doesn't. So, we need the flags to include
> (OSC_ACTIVE_STATE_PWR_SUPPORT | OSC_CLOCK_PWR_CAPABILITY_SUPPORT)
I'm experiencing a stall with Ceph daemons communicating over TCP that
occurs reliably with 3.6-rc1 (and linus/master) but not 3.5. The basic
situation is:
- the socket is two processes communicating over TCP on the same host, e.g.
tcp0 2164849 10.214.132.38:6801
Add information about the Exynos4210 pin banks and driver data which is
used by the Samsung pinctrl driver. In addition to this, the support for
external gpio and wakeup interrupt support is included and hooked up with
the Samsung pinctrl driver.
Cc: Linus Walleij
Cc: Kukjin Kim
Signed-off-by:
Pinctrl driver includes support for configuring the external wakeup
interrupts. On exynos platforms that use pinctrl driver, the setup
of wakeup interrupts in the exynos platform code can be skipped.
Cc: Kukjin Kim
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/common.c | 26
Pinctrl driver, when enabled, registers all the gpio pins and hence the
registration of gpio pins by this driver can be skipped.
Acked-by: Grant Likely
Acked-by: Linus Walleij
Signed-off-by: Thomas Abraham
---
drivers/gpio/gpio-samsung.c | 21 +
1 files changed, 21
Add a new device tree enabled pinctrl and gpiolib driver for Samsung
SoC's. This driver provides a common and extensible framework for all
Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This
driver supports only device tree based instantiation and hence can be
used only on
Changes since v1:
- Added support for external gpio and wakeup interrupts for Exynos4.
This patch series adds a common pinctrl driver for all Samsung platforms and
enables the pinctrl driver support for Exynos4210 based device tree enabled
platforms. The scope of this driver is limited to only
On Wed, 15 Aug 2012, Alexey Khoroshilov wrote:
> Several improvements in error handling:
> - do not report success if alloc_chrdev_region() failed
> - check for error code of cdev_add()
> - use unregister_chrdev_region() instead of unregister_chrdev()
> if class_create() failed
>
> Found by
On Wed, Aug 15, 2012 at 12:20 PM, Ezequiel Garcia wrote:
> Hi Steven,
>
> This patch is my first attempt to address the "early tracing issue".
> Right now, trace events are registered on fs_initcall, which is very late
> if you want to capture boot-up events.
>
> This feature is in developers
On 08/15/2012 09:12 PM, Greg Thelen wrote:
> On Wed, Aug 15 2012, Glauber Costa wrote:
>
>> On 08/15/2012 08:38 PM, Greg Thelen wrote:
>>> On Wed, Aug 15 2012, Glauber Costa wrote:
>>>
On 08/14/2012 10:58 PM, Greg Thelen wrote:
> On Mon, Aug 13 2012, Glauber Costa wrote:
>
>
The util-linux release v2.22-rc2 is available at
ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.22/
Feedback and bug reports, as always, are welcomed.
Karel
--
Karel Zak
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Several improvements in error handling:
- do not report success if alloc_chrdev_region() failed
- check for error code of cdev_add()
- use unregister_chrdev_region() instead of unregister_chrdev()
if class_create() failed
Found by Linux Driver Verification project (linuxtesting.org).
On Mon, 2012-08-13 at 10:26 -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> When we write entropy into a non-empty pool, we currently don't
> account at all for the fact that we will probabilistically overwrite
> some of the entropy in that pool.
Technically, no, nothing is
On Wed, Aug 15, 2012 at 05:22:19PM +0200, Martin Schwidefsky wrote:
> On Tue, 14 Aug 2012 16:16:49 +0200
> Frederic Weisbecker wrote:
>
> > The archs that implement virtual cputime accounting all
> > flush the cputime of a task when it gets descheduled
> > and sometimes set up some ground
On 08/15/2012 10:25 PM, Christoph Lameter wrote:
> On Wed, 15 Aug 2012, Ying Han wrote:
>
>>> How can you figure out which objects belong to which memcg? The ownerships
>>> of dentries and inodes is a dubious concept already.
>>
>> I figured it out based on the kernel slab accounting.
>>
On 08/08/2012 07:54 PM, Tony Prisk wrote:
> This patchset updates arch-vt8500 to devicetree and removes all the old-style
> code. Support for WM8650 has also been added.
Sorry for taking such a long time to re-review this.
I scanned the series looking for just the changes to the issues I raised
On Wed, Aug 15, 2012 at 10:47:38AM -0600, Alex Williamson wrote:
> On Wed, 2012-08-15 at 15:27 +0300, Michael S. Tsirkin wrote:
> > On Fri, Aug 10, 2012 at 04:37:17PM -0600, Alex Williamson wrote:
> > > Registering an kvm_irq_ack_notifier with kian.irq_source_id < 0
> > > retains existing
On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote:
> On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote:
> > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote:
> > > v8:
> > >
> > > Trying a new approach. Nobody seems to like the internal IRQ
> > > source ID
On Sat, Aug 4, 2012 at 3:27 PM, Rafael J. Wysocki wrote:
>
> If a PCI device is put into D3_cold by acpi_bus_set_power(),
> the message printed by acpi_pci_set_power_state() says that its
> power state has been changed to D4, which doesn't make sense.
> In turn, if the device is put into D3_hot,
>From 0cdf3aff, "ARM: SAMSUNG: use spin_lock_irqsave() in
clk_{enable,disable}":
The clk_enable()and clk_disable() can be used process and ISR either.
And actually it is used for real product and other platforms use it
now. So spin_lock_irqsave() should be used instead.
We need to make a
On Sun, Aug 12, 2012 at 3:26 PM, Rafael J. Wysocki wrote:
>
> Commit dbf0e4c (PCI: EHCI: fix crash during suspend on ASUS
> computers) added a workaround for an ASUS suspend issue related to
> USB EHCI and a bug in a number of ASUS BIOSes that attemt to shut
> down the EHCI controller during
On Mon, Jun 4, 2012 at 1:44 AM, Jiang Liu wrote:
> Commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a (PCI / ACPI: Make acpiphp
> ignore root bridges using PCIe native hotplug) added code that made the
> acpiphp driver completely ignore PCIe root complexes for which the kernel
> had been granted
On Wed, Aug 15, 2012 at 04:00:40PM +0200, Florian Westphal wrote:
> else, host continues to update stealtime after reboot,
> which can corrupt e.g. initramfs area.
> found when tracking down initramfs unpack error on initial reboot
> (with qemu-kvm -smp 2, no problem with single-core).
>
>
On Wed, Aug 15, 2012 at 05:03:47PM +0200, Martin Schwidefsky wrote:
> On Tue, 14 Aug 2012 16:16:47 +0200
> Frederic Weisbecker wrote:
>
> > S390, ia64 and powerpc all define their own version
> > of CONFIG_VIRT_CPU_ACCOUNTING. Generalize the config
> > and its description to a single place to
I'm announcing the release of the 3.0.41 kernel.
All users of the 3.0 kernel series must upgrade.
The updated 3.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.0.y
and can be browsed at the normal kernel.org git web browser:
Hi,
On Wed, Aug 15, 2012 at 06:37:11PM +0100, Catalin Marinas wrote:
> Hi Olof,
>
> > Given the recent development of ARM platforms, you might want to mandate
> > the state of IOMMUs as well (they should probably be off, since there
> > should be no active DMA activity). Graphics would be the
On 08/14/2012 04:57 AM, Minchan Kim wrote:
This patch introudes MIGRATE_DISCARD mode in migration.
It drop clean cache pages instead of migration so that
migration latency could be reduced. Of course, it could
evict code pages but latency of big contiguous memory
is more important than some
On Wed, Aug 15, 2012 at 04:05:21PM +0100, Anthony Olech wrote:
>
> if HAS_IOMEM
> +
> menu "Multifunction device drivers"
This random change is still present from the first version
> + /*
> + * the init_board_irq() call-back function should be defined in
> + * the machine
On 08/14/2012 04:57 AM, Minchan Kim wrote:
Now cma reclaims too many pages by __reclaim_pages which says
following as
* Reclaim enough pages to make sure that contiguous allocation
* will not starve the system.
Starve? What does it starve the system? The function which
On Wed, Aug 15, 2012 at 11:44 AM, Alan Cox wrote:
>> It sounds like get_task_comm shouldn't have locking at all then? It
>> should just do a length-limited copy and make sure there is a trailing
>> 0-byte?
>
> It has locking so that it has a consistent state and more importantly it
> has an
On Wed, Aug 15, 2012 at 11:07:01PM +0530, Naveen N. Rao wrote:
> Hi Frederick,
> Did you get a chance to take a look at this?
>
> Regards,
> Naveen
Yeah, I'm ok with the patch. Peter, are you ok with it?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
The core ptrace access checking routine holds a task lock, and when
reporting a failure, Yama takes a separate task lock. To avoid a
potential deadlock with two ptracers taking the opposite locks, do not
use get_task_comm() and just use ->comm directly since accuracy is not
important for the
301 - 400 of 1534 matches
Mail list logo
