This driver can be built as a module, add MODULE_ALIAS for it.
Signed-off-by: Axel Lin
---
drivers/regulator/max8907-regulator.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/max8907-regulator.c
b/drivers/regulator/max8907-regulator.c
index 3a5104f..19c765a 100644
---
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
transparent huge pages that could be used by the guest workload.
Besides ma
This patch introduces a new set of vm event counters to keep track of
ballooned pages compaction activity.
Signed-off-by: Rafael Aquini
---
drivers/virtio/virtio_balloon.c | 1 +
include/linux/vm_event_item.h | 8 +++-
mm/balloon_compaction.c | 2 ++
mm/migrate.c
The PATCH "mm: introduce compaction and migration for virtio ballooned pages"
hacks around putback_lru_pages() in order to allow ballooned pages to be
re-inserted on balloon page list as if a ballooned page was like a LRU page.
As ballooned pages are not legitimate LRU pages, this patch introduces
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
transparent huge pages that could be used by the guest workload.
This patch
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
transparent huge pages that could be used by the guest workload.
This patch
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
transparent huge pages that could be used by the guest workload.
This patch
On Fri, Aug 24, 2012 at 9:24 PM, Jacob Shin wrote:
> On Fri, Aug 24, 2012 at 06:07:01PM -0700, Yinghai Lu wrote:
>> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
>> > Currently direct mappings are created for [ 0 to max_low_pfn<> > and [ 4GB to max_pfn<> > backed by actual DRAM. This is fine
On Fri, Aug 24, 2012 at 06:23:48PM -0700, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> > There could be cases where user supplied memmap=exactmap memory
> > mappings do not mark the region where the kernel .text .data and
> > .bss reside as E820_RAM as reported here:
>
* Tejun Heo (t...@kernel.org) wrote:
> Hello,
>
> On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> > Thats the thing, the amount of things of things you can do with a given
> > bucket
> > is very limited. You can't add entries to any point besides the head
> > (without
> > walking
On Fri, Aug 24, 2012 at 06:07:01PM -0700, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> > Currently direct mappings are created for [ 0 to max_low_pfn< > and [ 4GB to max_pfn< > backed by actual DRAM. This is fine for holes under 4GB which are covered
> > by fixed and va
On 08/24/2012 09:20 PM, Jacob Shin wrote:
What is the benefit?
So that in the case where we have E820_RAM right above 1MB, we don't
call init_memory_mapping twice, first on 0 ~ 1MB and then 1MB ~ something
we only call it once. 0 ~ something.
So what is the benefit?
-hpa
--
H. P
On Fri, Aug 24, 2012 at 06:13:02PM -0700, H. Peter Anvin wrote:
> On 08/24/2012 05:49 PM, Jacob Shin wrote:
> >
> > Right, I think what I was attempting to do was to merge the 1MB
> > with E820_RAM right above 1MB:
> >
> > So instead of:
> >
> > init_memory_mapping(0, 1MB)
> > init_memory_mappin
On Fri, Aug 24, 2012 at 07:06:42PM -0700, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 6:49 PM, Yinghai Lu wrote:
> > On Fri, Aug 24, 2012 at 6:25 PM, Yinghai Lu wrote:
> >> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> >>> Depending on the platform, init_memory_mapping() may be called mul
On Fri, Aug 24, 2012 at 06:25:38PM -0700, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> > Depending on the platform, init_memory_mapping() may be called multiple
> > times. Move it out to setup_arch() to avoid writing to cr4 on every call.
> >
> > Signed-off-by: Jacob Sh
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 9b7de93..fef6b3c 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt61
+-rt62-rc1
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsub
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> > On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> > > Hi,
> > >
> > > Changes since v1:
> > >
> > > - Fixed preempt handling in alpha idle loop
> >
Updates console-make-rt-friendly.patch
#ifdef CONFIG_PREEMPT_RT_FULL, printk() output is never flushed by
printk() because:
# some liberties taken in this pseudo-code to make it easier to follow
printk()
vprintk()
raw_spin_lock(&logbuf_lock)
# increment preempt_co
Dear RT Folks,
This is the RT stable review cycle of patch 3.0.41-rt62-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release cand
On Fri, Aug 24, 2012 at 12:06 PM, G.Shark Jeong wrote:
> From: "G.Shark Jeong"
>
> LM3554 and LM3556 have similar functions but very different register map.
> This driver is a general version for LM355x,lm3554 and lm3556,led chips of TI.
> lm3556 driver can be replaced by this driver.
>
> LM3554
On 08/24/2012 06:36 PM, Bill Huang wrote:
>>> On Sun, Aug 19, 2012 at 06:07:55PM -0700, Bill Huang wrote:
Add DT property "ti,system-power-controller" telling whether or not
this pmic is in charge of controlling the system power, so the power
off routine can be hooked up to system ca
On 08/23/2012 01:35 AM, Tony Prisk wrote:
> This patchset updates arch-vt8500 to devicetree and removes all the old-style
> code. Support for WM8650 has also been added.
>
> Example dts/dtsi files are given for the three currently supported models.
>
> Major changes:
>
> GPIO code has been conve
This complements patch "net-forcedeth: fix TX timeout caused by TX
pause on down link" which ensures that a lock-up sequence is not sent
to the NIC. Present patch ensures that if a NIC is already locked-up,
the driver will recover from it when initializing the device.
It does the equivalent of the
On some dual-port forcedeth devices such as MCP55 10de:0373 (rev a3),
when autoneg & TX pause are enabled while port is connected but
interface is down, the NIC will eventually freeze (TX timeouts,
network unreachable).
This patch ensures that TX pause is not configured in hardware when
interface
Found by manual code inspection.
Tested: compile, reboot, ethtool -d ethX
Signed-off-by: David Decotigny
---
drivers/net/ethernet/nvidia/forcedeth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c
b/drivers/net/ethernet/nvidia/for
On a dual port MCP55 10de:0373 (rev a3) NIC with both ports connected,
we identified a configuration that does freeze the whole NIC: having
autoneg & TX pause turned on while one port is physically connected
but interface is down (eg. eth1) eventually causes the whole NIC to
freeze (eth1 and... eth
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 629e0b4..31c892a 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt41
+-rt42-rc1
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsub
Updates console-make-rt-friendly.patch
#ifdef CONFIG_PREEMPT_RT_FULL, printk() output is never flushed by
printk() because:
# some liberties taken in this pseudo-code to make it easier to follow
printk()
vprintk()
raw_spin_lock(&logbuf_lock)
# increment preempt_co
Dear RT Folks,
This is the RT stable review cycle of patch 3.2.28-rt42-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release cand
Dear RT Folks,
I'm pleased to announce the 3.2.28-rt41 stable release.
This release is just an update to the new stable 3.2.28 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.g
On Fri, 2012-08-24 at 22:37 -0400, Steven Rostedt wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.2.27-rt40 stable release.
Bah, Evolution is crashing on my /tmp directory (where my scripts place
the files). There's a bug in the gtk4 file manager (I'm using xfce),
where if the directory
Dear RT Folks,
I'm pleased to announce the 3.2.27-rt40 stable release.
This release is just an update to the new stable 3.2.27 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.g
Assume we have a 1GB(8Gb) nand chip, and we set the partitions
in the command line like this:
#gpmi-nand:100m(boot),100m(kernel),1g(rootfs)
In this case, the partition truncating occurs. The current code will
get the following result:
--
root@frees
From: Wei Yongjun
Remove including that don't need it.
Signed-off-by: Wei Yongjun
---
kernel/kexec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 0668d58..5e4bd78 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -21,7 +21,6 @@
#include
#inclu
On 25/08/12 13:19, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
>> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
>>> Hi,
>>>
>>> Changes since v1:
>>>
>>> - Fixed preempt handling in alpha idle loop
>>> - added ack from Geert
>>> - fixed s
On Fri, Aug 24, 2012 at 6:49 PM, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 6:25 PM, Yinghai Lu wrote:
>> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
>>> Depending on the platform, init_memory_mapping() may be called multiple
>>> times. Move it out to setup_arch() to avoid writing to cr4
On Fri, Aug 24, 2012 at 6:25 PM, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
>> Depending on the platform, init_memory_mapping() may be called multiple
>> times. Move it out to setup_arch() to avoid writing to cr4 on every call.
>>
>> Signed-off-by: Jacob Shin
>> ---
>
From: Wei Yongjun
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun
---
drivers/staging/csr/sme_wext.c | 4 +---
1 f
On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> Depending on the platform, init_memory_mapping() may be called multiple
> times. Move it out to setup_arch() to avoid writing to cr4 on every call.
>
> Signed-off-by: Jacob Shin
> ---
> arch/x86/kernel/setup.c | 10 ++
> arch/x86/mm/
On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> There could be cases where user supplied memmap=exactmap memory
> mappings do not mark the region where the kernel .text .data and
> .bss reside as E820_RAM as reported here:
>
> https://lkml.org/lkml/2012/8/14/86
>
> Handle it by complaining, a
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> > Hi,
> >
> > Changes since v1:
> >
> > - Fixed preempt handling in alpha idle loop
> > - added ack from Geert
> > - fixed stable email address, sorry :-/
> >
> > T
On 08/24/2012 05:49 PM, Jacob Shin wrote:
>
> Right, I think what I was attempting to do was to merge the 1MB
> with E820_RAM right above 1MB:
>
> So instead of:
>
> init_memory_mapping(0, 1MB)
> init_memory_mapping(1MB, 2GB)
>
> It would be:
>
> init_memory_mapping(0, 2GB)
>
> While taking c
On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> Currently direct mappings are created for [ 0 to max_low_pfn< and [ 4GB to max_pfn< backed by actual DRAM. This is fine for holes under 4GB which are covered
> by fixed and variable range MTRRs to be UC. However, we run into trouble
> on higher
On Fri, 2012-08-24 at 09:41 -0400, Steven Rostedt wrote:
> On Fri, 2012-08-24 at 15:15 +0800, Fengguang Wu wrote:
> > Hi Steven,
> >
> > The following test fails are mostly due to this commit, or one of the
> > last 4 commits in
> >
> > tree:
> > git://git.kernel.org/pub/scm/linux/kernel/git/
On 25/08/12 02:36, Alan Cox wrote:
>> almost all x86-32 boxes will be trash in 2017, remaining boxes will
>> use long term tree
> People will still be manufacturing 32bit x86 processors in 2017 I'm quite
> sure. You appear entirely out of touch. There are already serious
> discussions going on abou
DIV_ROUND_CLOSEST returns a bad result for negative dividends:
DIV_ROUND_CLOSEST(-2, 2) = 0
Most of the time this does not matter. However, in the hardware monitoring
subsystem, it is often used on integers which can be negative (such as
temperatures). Introduce new macro IDIV_ROUND_CLOSES
On 25/08/12 03:05, wbrana wrote:
> On 8/24/12, Martin Nybo Andersen wrote:
>> What I'd hate even more is rendering my old working hardware useless by
>> removing x86-32 support from the kernel. To reason the removal by saying
>> "Microsoft plans to do it" just makes me go bonkers...
> Your old har
On Fri, Aug 24, 2012 at 05:30:21PM -0700, H. Peter Anvin wrote:
> On 08/24/2012 04:55 PM, Jacob Shin wrote:
> >+
> >+for (i = 0; i < e820.nr_map; i++) {
> >+struct e820entry *ei = &e820.map[i];
> >+u64 start = ei->addr;
> >+u64 end = ei->addr + ei->size;
> >+
nvpublic
> > On Sun, Aug 19, 2012 at 06:07:55PM -0700, Bill Huang wrote:
> > > Add DT property "ti,system-power-controller" telling whether or not
> > > this pmic is in charge of controlling the system power, so the power
> > > off routine can be hooked up to system call "pm_power_off".
> > >
> > >
Andrew Morton writes:
> On Fri, 17 Aug 2012 21:24:08 -0400
> Ed Cashin wrote:
...
>> +sigfillset(&blocked);
>> +sigprocmask(SIG_BLOCK, &blocked, NULL);
>> +flush_signals(current);
>
> This is a kernel thread - it shouldn't need to fiddle with signals.
...
Thanks for the feedback. I
On 08/24/2012 04:55 PM, Jacob Shin wrote:
+
+ for (i = 0; i < e820.nr_map; i++) {
+ struct e820entry *ei = &e820.map[i];
+ u64 start = ei->addr;
+ u64 end = ei->addr + ei->size;
+
+ /* we only map E820_RAM */
+ if (ei->ty
Quoting Chao Xie (2012-08-19 19:55:10)
> From: Chao Xie
> arch/arm/mach-mmp/Kconfig|3 +
> drivers/clk/Makefile |3 +
> drivers/clk/mmp/Makefile |9 +
> drivers/clk/mmp/clk-apbc.c | 152 ++
> drivers/clk/mmp/clk-apmu.c | 97 +
> drivers/clk/m
On Fri, Aug 24, 2012 at 06:55:14PM -0500, Jacob Shin wrote:
> Currently direct mappings are created for [ 0 to max_low_pfn< and [ 4GB to max_pfn< backed by actual DRAM. This is fine for holes under 4GB which are covered
> by fixed and variable range MTRRs to be UC. However, we run into trouble
> on
nvpublic
> On Fri, Aug 24, 2012 at 04:23:39PM +0800, Bill Huang wrote:
> > When doing shutdown on Tegra20/Tegra30, we need to read/write PMIC
> > registers through I2C to perform the power off sequence.
> > Unfortunately, sometimes we'll fail to shutdown due to I2C timeout on
> > Tegra20. And the c
[second send after HTML part made vger reject my first email]
On 32 Aug 2012, Ed Cashin writes:
> These patches go a long way to updating the in-kernel aoe driver with
> the changes that have been in the coraid.com-distributed version,
> bringing it from (aoe internal) version 47 to version 49.
Currently direct mappings are created for [ 0 to max_low_pfn<
---
arch/x86/include/asm/page_types.h |9 +++
arch/x86/kernel/setup.c | 125 +
arch/x86/mm/init.c|2 +
arch/x86/mm/init_64.c |6 +-
4 files changed,
Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()
This patch also reportedly fixes suspend/resume issue reported in:
Currently kernel direct mappings are created for all pfns between
[ 0 to max_low_pfn ) and [ 4GB to max_pfn ). When we introduce memory
holes, we end up mapping memory ranges that are not backed by physical
DRAM. This is fine for lower memory addresses which can be marked as UC
by fixed/variable ra
There could be cases where user supplied memmap=exactmap memory
mappings do not mark the region where the kernel .text .data and
.bss reside as E820_RAM as reported here:
https://lkml.org/lkml/2012/8/14/86
Handle it by complaining, and adding the range back into the e820.
Signed-off-by: Jacob Sh
Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.
Signed-off-by: Jacob Shin
---
arch/x86/kernel/cpu/amd.c |6 +-
arch/x86/platform/efi/efi.c |8
2 files chan
Depending on the platform, init_memory_mapping() may be called multiple
times. Move it out to setup_arch() to avoid writing to cr4 on every call.
Signed-off-by: Jacob Shin
---
arch/x86/kernel/setup.c | 10 ++
arch/x86/mm/init.c | 10 --
2 files changed, 10 insertions(+),
On Fri, Aug 24, 2012 at 11:22:05PM +0530, Laxman Dewangan wrote:
> I tried to reproduce the issue but could not able to do this.
> Can you please send me your board/dt files where you are porviding
> platform data for regulator?
> This will help me to reproduce the issue.
Here's a dts patch:
diff
Signed-off-by: Dave Jiang
---
drivers/dma/ioat/pci.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
index 5e3a40f..c057306 100644
--- a/drivers/dma/ioat/pci.c
+++ b/drivers/dma/ioat/pci.c
@@ -40,6 +40
-Original Message-
From: Theodore Ts'o [mailto:ty...@mit.edu]
Sent: Friday, August 24, 2012 6:39 PM
To: Justin Piszcz
Cc: linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org; al piszcz
Subject: Re: 3.5.1 kernel: Oops + stracktrace + ext4 kernel errors!
On Fri, Aug 24, 2012 at 11:31
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> Thats the thing, the amount of things of things you can do with a given bucket
> is very limited. You can't add entries to any point besides the head (without
> walking the entire list).
Kinda my point. We already have all the
On Sun, Aug 19, 2012 at 08:57:04PM -0700, Greg Kroah-Hartman wrote:
> From: Greg KH
>
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Daniel Vetter
>
> commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream.
>
> We may only sta
>> Why do we need hash_head/hash_for_each_head()? I haven't stumbled on a place
>> yet
>> that needed direct access to the bucket itself.
>
> Because whole hash table walking is much less common and we can avoid
> another full set of iterators.
I don't agree. Out of 32 places which now use a has
Hello,
On Thu, Aug 23, 2012 at 04:53:27PM -0400, a...@redhat.com wrote:
> This series are a refreshed version of a patchset submitted by Li Zefan back
> in march:
> https://lkml.org/lkml/2012/3/1/13
Applied to cgroup/for-3.7 w/ "Original-Patch-by: Li Zefan" added for
the first three patches
On Fri, Aug 24, 2012 at 11:31:44AM -0400, Justin Piszcz wrote:
> Hello,
>
> Thoughts?
>
> Saw this when trying to copy files to array with Samba and doing file
> operations:
>
> [28939.505792] [ cut here ]
> [29367.345433] BUG: unable to handle kernel NULL pointer derefer
On Thu, 2012-08-23 at 15:26 +0200, Borislav Petkov wrote:
> On Fri, Aug 10, 2012 at 10:05:53AM +0800, Aaron Lu wrote:
> > commit a606dac368eed5696fb38e16b1394f1d049c09e9 adds support to link
> > devices which have _PRx, if a device does not have _PRx, a warning
> > message will be printed.
> >
> >
On Fri, 24 Aug 2012 14:03:23 +0900
GShark Jeong wrote:
> I've reviewed and tested you patch ( lm3630 and lm3639) on my real board
> and these are working well .
> Thank you.
Great, thanks.
> ( Do I need to send back this patch to you again? or will the current
> status be applied for next bran
On Fri, Aug 24, 2012 at 11:30:12PM +0200, Daniel Mack wrote:
> On Fri, Aug 24, 2012 at 9:08 PM, Josh Boyer wrote:
> > Hi All,
> >
> > We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> > working with 3.6-rc3. It seems the last working kernel was based on
> > commit 10c63c9
Hi,
On 24.08.2012 21:08, Josh Boyer wrote:
> We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> working with 3.6-rc3. It seems the last working kernel was based on
> commit 10c63c9, and it first stopped working with a kernel based on
> commit 23dcfa6. There are only a few
Commit-ID: 127f5403bfbc5f52cf0fbbadfa5e624a32a137ff
Gitweb: http://git.kernel.org/tip/127f5403bfbc5f52cf0fbbadfa5e624a32a137ff
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:02 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:54 -0700
x86, fpu: use non-lazy
Commit-ID: 1ce83ffda9aea53e6e4b6b6a82c028a019526010
Gitweb: http://git.kernel.org/tip/1ce83ffda9aea53e6e4b6b6a82c028a019526010
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:01 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:52 -0700
lguest, x86: handle gue
This is a fixup patch for the merge of drm-next into linux-next caused
by commit b6c7488df68a ("drm/i915/contexts: fix list corruption").
Reported-By: Stephen Rothwell
Signed-off-by: Sedat Dilek
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
Reported-By: Stephen Rothwell
Acked-by: Jani Nikula
Acked-by: Dave Airlie
Signed-off-by: Sedat Dilek
---
drivers/gpu/drm/i915/intel_modes.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_modes.c
b/drivers/gpu/drm/i915/intel_modes.c
index 29b7259..4bc1c0f 1006
In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
statement.
In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
but selects USB_SUPPORT which leads to the error for udl Kconfig:
$ yes "" | make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drive
Commit-ID: 964735018df03c94dd12665385d59e3b2c7c08b8
Gitweb: http://git.kernel.org/tip/964735018df03c94dd12665385d59e3b2c7c08b8
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:00 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:50 -0700
x86, fpu: always use ke
Commit-ID: 98700fa647b3572f7fa55485570ab9fc53b91d23
Gitweb: http://git.kernel.org/tip/98700fa647b3572f7fa55485570ab9fc53b91d23
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:59 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:49 -0700
x86, kvm: use kernel_fp
Commit-ID: cc50fae05beb2db9f4587bbb1a0d6aba2af5b407
Gitweb: http://git.kernel.org/tip/cc50fae05beb2db9f4587bbb1a0d6aba2af5b407
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:58 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:48 -0700
x86, fpu: remove unnece
Some of our language runtimes like to map IP addresses in perf backtrace
to specific byte codes. The way things stand now, the addresses on the
backtrace are return addresses, rather than the caller. I think this
issue may be present for other unusual call/return sequences where the
user may be
Commit-ID: 739390035c5fba2132fa424309786ff7bdd2cc1e
Gitweb: http://git.kernel.org/tip/739390035c5fba2132fa424309786ff7bdd2cc1e
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:57 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:47 -0700
x86, fpu: drop_fpu() be
On Thu, 23 Aug 2012 19:36:08 +0400
Glauber Costa wrote:
> When we want to duplicate a new process, dup_task_struct() will undergo
> a series of allocations. If alloc_thread_info_node() fails, we call
> free_task_struct() and return.
>
> This seems right, but it is not. free_task_struct() will no
On Thu, 23 Aug 2012 18:36:02 +0100
Will Deacon wrote:
> On Thu, Aug 23, 2012 at 06:11:56PM +0100, Michal Hocko wrote:
> > On Thu 23-08-12 17:37:13, Will Deacon wrote:
> > > The core page allocator ensures that page flags are zeroed when freeing
> > > pages via free_pages_check. A number of archit
Hello Kurt,
On Fri, Aug 24, 2012 at 02:42:48PM +0200, Kurt Van Dijck wrote:
> On Fri, Aug 24, 2012 at 01:28:16PM +0200, Marc Kleine-Budde wrote:
> > On 08/24/2012 07:10 AM, Kurt Van Dijck wrote:
> > > Hello,
> > >
> > > I find the CAN led triggers an interesting thing.
> > >
> > > And then, this
Hello,
On Thu, Aug 23, 2012 at 04:31:43PM -0400, Naoya Horiguchi wrote:
> On Thu, Aug 23, 2012 at 05:11:25PM +0800, Fengguang Wu wrote:
> > On Wed, Aug 22, 2012 at 11:17:35AM -0400, Naoya Horiguchi wrote:
...
> > > diff --git v3.6-rc1.orig/fs/inode.c v3.6-rc1/fs/inode.c
> > > index ac8d904..874239
On Fri, 24 Aug 2012 22:37:55 +0800
Wanpeng Li wrote:
> From: Gavin Shan
>
> While registering MMU notifier, new instance of MMU notifier_mm will
> be allocated and later free'd if currrent mm_struct's MMU notifier_mm
> has been initialized. That cause some overhead. The patch tries to
> elemina
On 08/15/2012 10:28 AM, Stephen Warren wrote:
> From: Gyungoh Yoo
>
> The MAX8907 is an I2C-based power-management IC containing voltage
> regulators, a reset controller, a real-time clock, and a touch-screen
> controller.
Samuel,
Does this look OK now? (although you're probably traveling to a
On Fri, Aug 24, 2012 at 11:45:45AM -0500, Nathan Zimmer wrote:
> On 08/24/2012 09:58 AM, Eric Dumazet wrote:
>> Le vendredi 24 août 2012 à 09:48 -0500, Nathan Zimmer a écrit :
>>> On Wed, Aug 22, 2012 at 11:42:58PM +0200, Eric Dumazet wrote:
On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrot
I have applied this to tip:x86/fpu, but I have also asked Suresh to
prepare a followon patch to decouple eager save from the existence of
the XSAVE instruction. It seems pretty clear that eager save is a net
benefit in the presence of the XSAVEOPT, but it isn't as clear for only
having XSAVE, as f
On Fri, Aug 24, 2012 at 9:08 PM, Josh Boyer wrote:
> Hi All,
>
> We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> working with 3.6-rc3. It seems the last working kernel was based on
> commit 10c63c9, and it first stopped working with a kernel based on
> commit 23dcfa6.
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> Hi,
>
> Changes since v1:
>
> - Fixed preempt handling in alpha idle loop
> - added ack from Geert
> - fixed stable email address, sorry :-/
>
> This time I built tested everywhere but: h8300 (compiler internal error),
> and
* Felipe Balbi [120823 03:37]:
> The driver doesn't need to know about its platform_device.
>
> Everything the driver needs can be done through the
> struct device pointer. In case we need to use the
> OMAP-specific PM function pointers, those can make
> sure to find the device's platform_device
Hello,
On Fri, Aug 24, 2012 at 10:53:45PM +0200, Sasha Levin wrote:
> Yup, but we could be using the same API for dynamic non-resizable and static
> if
> we go with the DECLARE/hash_init. We could switch between them (and other
> implementations) without having to change the code.
I think it's b
On Fri, 17 Aug 2012 21:24:08 -0400
Ed Cashin wrote:
> This patch makes the frames the aoe driver uses to track the
> relationship between bios and packets more flexible and detached, so
> that they can be passed to an "aoe_ktio" thread for completion of I/O.
>
> The frames are handled much like
No need to save the state with unlazy_fpu(), that is about to get overwritten
by the state from the signal frame. Instead use drop_fpu() and continue
to restore the new state.
Also fold the stop_fpu_preload() into drop_fpu().
Signed-off-by: Suresh Siddha
---
arch/x86/include/asm/fpu-internal.h
kvm's guest fpu save/restore should be wrapped around
kernel_fpu_begin/end(). This will avoid for example taking a DNA
in kvm_load_guest_fpu() when it tries to load the fpu immediately
after doing unlazy_fpu() on the host side.
More importantly this will prevent the host process fpu from being
cor
use kernel_fpu_begin/end() instead of unconditionally accessing cr0 and
saving/restoring just the few used xmm/ymm registers.
This has some advantages like:
* If the task's FPU state is already active, then kernel_fpu_begin()
will just save the user-state and avoiding the read/write of cr0.
In
Fundamental model of the current Linux kernel is to lazily init and
restore FPU instead of restoring the task state during context switch.
This changes that fundamental lazy model to the non-lazy model for
the processors supporting xsave feature.
Reasons driving this model change are:
i. Newer pr
1 - 100 of 483 matches
Mail list logo
