30fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to
> store a per interrupt XEN data pointer which contains XEN specific
> information.")
> Signed-off-by: Juergen Gross
Tested-by: Stefan Bader
> ---
> drivers/xen/events/events_base.c | 29 +---
On 29.09.20 16:05, Jürgen Groß wrote:
> On 29.09.20 15:13, Stefan Bader wrote:
>> On 01.09.20 17:10, Greg Kroah-Hartman wrote:
>>> From: Thomas Gleixner
>>>
>>> commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream.
>>>
>>> handler data i
On 29.09.20 16:05, Jürgen Groß wrote:
> On 29.09.20 15:13, Stefan Bader wrote:
>> On 01.09.20 17:10, Greg Kroah-Hartman wrote:
>>> From: Thomas Gleixner
>>>
>>> commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream.
>>>
>>> handler data i
On 01.09.20 17:10, Greg Kroah-Hartman wrote:
> From: Thomas Gleixner
>
> commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream.
>
> handler data is meant for interrupt handlers and not for storing irq chip
> specific information as some devices require handler data to store internal
> per int
On 29.05.19 12:37, Greg KH wrote:
> On Wed, May 29, 2019 at 12:25:39PM +0200, Stefan Bader wrote:
>> From: Jiri Wiesner
>>
>> The *_frag_reasm() functions are susceptible to miscalculating the byte
>> count of packet fragments in case the truesize of a head buffer chan
On 29.05.19 12:37, Greg KH wrote:
> On Wed, May 29, 2019 at 12:25:39PM +0200, Stefan Bader wrote:
>> From: Jiri Wiesner
>>
>> The *_frag_reasm() functions are susceptible to miscalculating the byte
>> count of packet fragments in case the truesize of a head buffer chan
g_queue()
Jiri Wiesner (1):
ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes
Peter Oskolkov (2):
ip: fail fast on IP defrag errors
net: IP defrag: encapsulate rbtree defrag code into callable functions
Stefan Bader (1):
ipv6: frags: Use inet_frag_pull
stments in net/ipv6/netfilter/nf_conntrack_reasm.c]
Signed-off-by: Stefan Bader
---
net/ipv4/ip_fragment.c | 7 +++
net/ipv6/netfilter/nf_conntrack_reasm.c | 8 +++-
net/ipv6/reassembly.c | 8 +++-
3 files changed, 21 insertions(+), 2 deletions(-)
di
Herbert
Signed-off-by: David S. Miller
(backported from commit c23f35d19db3b36ffb9e04b08f1d91565d15f84f)
[smb: open code skb_mark_not_on_list(), context adjustments, use of
IP_INC_STATS_BH instead of __IP_INC_STATS]
Signed-off-by: Stefan Bader
---
include/net/inet_frag.h | 16 ++-
net/ipv4
[] __xfrm_decode_session+0x39/0x50
[] icmpv6_route_lookup+0xf0/0x1c0
[] icmp6_send+0x5e1/0x940
[] icmpv6_send+0x21/0x30
[] ip6_expire_frag_queue+0xe0/0x120
Signed-off-by: Stefan Bader
---
net/ipv6/reassembly.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/net
ragments
as overlapping"]
Signed-off-by: Stefan Bader
---
net/ipv4/ip_fragment.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 5387e6ab78d7..a53652c8c0fd 100644
--- a/net/ipv4/ip_fragm
On 22.05.19 21:15, Sasha Levin wrote:
> From: Eric Dumazet
>
> [ Upstream commit 47d3d7fdb10a21c223036b58bd70ffdc24a472c4 ]
>
> Since ip6frag_expire_frag_queue() now pulls the head skb
> from frag queue, we should no longer use skb_get(), since
> this leads to an skb le
On 03.07.2017 15:34, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
We found that pulling below patch into stable trees without also pulling
commit 9c3f3794926a997b1cab6c42480ff300efa2d162
Author: Liping Zhang
Date: Sat Mar 25 16:35:29 2
: partition support: add 16 minors per bcacheN device)
Cc: # v4.10
Signed-off-by: Stefan Bader
---
drivers/md/bcache/super.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 85e3f21..817e155 100644
--- a/drivers/md/bcache
On 28.07.2016 18:27, Stefan Bader wrote:
> On 28.07.2016 07:55, Kent Overstreet wrote:
>> On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote:
>>> So here is another attempt which does half the proposed changes. And before
>>> you
>>> point out that
On 28.07.2016 07:55, Kent Overstreet wrote:
> On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote:
>> So here is another attempt which does half the proposed changes. And before
>> you
>> point out that it looks still ugly, let me explain some reasons. The goal
>
On 26.07.2016 14:49, Kent Overstreet wrote:
> On Tue, Jul 26, 2016 at 02:32:31PM +0200, Stefan Bader wrote:
>> On 26.07.2016 12:21, Kent Overstreet wrote:
>>> On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote:
>>>> On 21.07.2016 10:58, Stefan Bader wro
On 26.07.2016 12:21, Kent Overstreet wrote:
> On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote:
>> On 21.07.2016 10:58, Stefan Bader wrote:
>>> I was pointed at the thread which seems to address the same after
>>> I wrote most of below text. Did not want
On 21.07.2016 10:58, Stefan Bader wrote:
> I was pointed at the thread which seems to address the same after
> I wrote most of below text. Did not want to re-write this so please
> bear with the odd layout.
>
> https://www.redhat.com/archives/dm-devel/2016-June/msg00015.html
>
On 17.05.2016 15:20, Stefan Bader wrote:
> Re-posting to a hopefully better suited audience. I hit this problem
> when trying to boot a i386 dom0 (PAE enabled) on a 64bit Xen host using
> a config which would result in a reserved memory range starting at 4MB.
Of course that ^ should be
as the type for start and end
as that is the type used in the memblock region definitions and those
are 64bit (at least with PAE enabled).
-Stefan
>From 1588a8b3983f63f8e690b91e99fe631902e38805 Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Tue, 10 May 2016 19:05:16 +0200
Subject: [PA
On 02.05.2016 16:24, Stefan Bader wrote:
> On 02.05.2016 13:41, Juergen Gross wrote:
>> On 02/05/16 12:47, Stefan Bader wrote:
>>> I recently tried to boot 32bit dom0 on 64bit Xen host which I configured to
>>> run
>>> with a limited, fix amount of memo
violation when writing 0 into writeback_running of a bcache device that
is not attached to a cache set (without the patch).
-Stefan
---
>From e949c64fa6acbdaab999410250855a6a4fc6bad1 Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Mon, 18 Aug 2014 20:00:13 +0200
Subject: [PATCH] bcache: prev
On 18.03.2015 10:18, Paolo Bonzini wrote:
>
>
> On 18/03/2015 09:46, Stefan Bader wrote:
>>
>> Regardless of that, I wonder whether the below (this version untested) sound
>> acceptable for upstream? At least it would make debugging much simpler. :)
>>
>>
On 18.03.2015 11:27, Paolo Bonzini wrote:
>
>
> On 18/03/2015 10:59, Stefan Bader wrote:
>>> @@ -2850,7 +2851,7 @@ static __init int setup_vmcs_config(struct
>>> vmcs_config *vmcs_conf) vmx_capability.ept,
>>> vmx_capability.vpid); }
>>>
>>>
On 18.03.2015 10:18, Paolo Bonzini wrote:
>
>
> On 18/03/2015 09:46, Stefan Bader wrote:
>>
>> Regardless of that, I wonder whether the below (this version untested) sound
>> acceptable for upstream? At least it would make debugging much simpler. :)
>>
>>
Someone reported[1] that some of their L1 guests fail to load the kvm-intel
module (without much details). Turns out that this was (at least) caused by
KVM: vmx: Allow the guest to run with dirty debug registers
as this adds VM_EXIT_SAVE_DEBUG_CONTROLS to the required MSR_IA32_VMX_EXIT_CTLS
bits.
ocki
> Cc: Len Brown
> Cc: Pavel Machek
> Cc: Bjorn Helgaas
> Link:
> http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Stefan Bader
> Signed-off-by: Greg Kroah-Hartman
>
> ---
&
On 09.02.2015 20:15, Sander Eikelenboom wrote:
>
> Monday, February 9, 2015, 5:09:44 PM, you wrote:
>
>> On 09.02.2015 13:29, Stefan Bader wrote:
>>> On 09.02.2015 13:12, Jiang Liu wrote:
>>>> On 2015/2/9 17:47, Stefan Bader wrote:
>>>>
On 09.02.2015 20:54, Sander Eikelenboom wrote:
> Hi.
>
> In 3.19 the device name associates with IRQ's for ahci controllers operating
> with a single IRQ changed from "ahci?" to "", was this intentional ?
>
> It's probably commit 18dcf433f3ded61eb140a55e7048ec2fef79e723 (or another one
> in that
On 09.02.2015 13:29, Stefan Bader wrote:
> On 09.02.2015 13:12, Jiang Liu wrote:
>> On 2015/2/9 17:47, Stefan Bader wrote:
>>> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>>>>
>>>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>>>>
On 09.02.2015 13:12, Jiang Liu wrote:
> On 2015/2/9 17:47, Stefan Bader wrote:
>> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>>>
>>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>>>
>>>> Hi Thomas,
>>>> This patch set i
e, there's no need for xen_setup_acpi_sci() anymore.
The above change also works with bare metal kernel too.
Signed-off-by: Jiang Liu
Tested-by: Sander Eikelenboom
Cc: Tony Luck
Cc: xen-de...@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk
Cc: David Vrabel
Cc: Rafael J. Wysocki
Cc: Len Brown
it would get pushed.
-Stefan
>
> On Tue, Aug 19, 2014 at 6:01 AM, Stefan Bader
> wrote:
>> commit a664d0f05a2ec02c8f042db536d84d15d6e19e81
>> bcache: fix crash on shutdown in passthrough mode
>>
>> added a safeguard in the shutdown case. At least while not bein
On 01.12.2014 14:59, Zoltan Kiss wrote:
>
>
> On 01/12/14 13:36, David Vrabel wrote:
>> On 01/12/14 08:55, Stefan Bader wrote:
>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>> There is a long known problem with the netfront/netback interface: if the
>>
On 11.08.2014 19:32, Zoltan Kiss wrote:
> There is a long known problem with the netfront/netback interface: if the
> guest
> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring
> slots,
> it gets dropped. The reason is that netback maps these slots to a frag in the
> frags a
On 07.11.2014 13:21, Zoltan Kiss wrote:
>
>
> On 07/11/14 12:15, Stefan Bader wrote:
>> On 07.11.2014 12:22, Eric Dumazet wrote:
>>> On Fri, 2014-11-07 at 09:25 +, Zoltan Kiss wrote:
>>>
>>> Please do not top post.
>>>
>>>> H
On 07.11.2014 12:22, Eric Dumazet wrote:
> On Fri, 2014-11-07 at 09:25 +, Zoltan Kiss wrote:
>
> Please do not top post.
>
>> Hi,
>>
>> AFAIK in this scenario your skb frag is wrong. The page pointer should
>> point to the original compound page (not a member of it), and offset
>> should be
On 07.11.2014 11:44, David Vrabel wrote:
> On 06/11/14 21:49, Seth Forshee wrote:
>> We've had several reports of hitting the following BUG_ON in
>> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
>> results of testing with 3.17):
>>
>> /* Grant backend access to each sk
On 02.09.2014 13:01, David Vrabel wrote:
> On 01/09/14 18:34, David Vrabel wrote:
>> On 29/08/14 16:17, Stefan Bader wrote:
>>>
>>> This change might not be the fully correct approach as it basically
>>> removes the pre-set page table entry for the
ll, something
does create entries at level2_fixmap_pgt[506..507]. So it should be
ok. At least I was able to successfully boot a kernel with 1G kernel
image size without any vmalloc whinings.
Signed-off-by: Stefan Bader
Cc: sta...@vger.kernel.org
---
arch/x86/xen/mmu.c | 26 +-
On 29.08.2014 16:31, David Vrabel wrote:
> On 29/08/14 15:27, Stefan Bader wrote:
>>
>> Ok, I rework the patch and re-send it (freshly, iow not part of this thread).
>> And while I am at it, I would add the stable tag.
>
> Can you use a different title? Perhaps:
>
On 29.08.2014 16:19, Andrew Cooper wrote:
> On 29/08/14 09:37, Stefan Bader wrote:
>> On 29.08.2014 00:42, Andrew Cooper wrote:
>>> On 28/08/2014 19:01, Stefan Bader wrote:
>>>>>> So not much further... but then I think I know what I do next. Probably
>>
On 29.08.2014 16:08, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 28, 2014 at 08:01:43PM +0200, Stefan Bader wrote:
>>>> So not much further... but then I think I know what I do next. Probably
>>>> should
>>>> have done before. I'll replace the WARN_
On 29.08.2014 00:42, Andrew Cooper wrote:
> On 28/08/2014 19:01, Stefan Bader wrote:
>>>> So not much further... but then I think I know what I do next. Probably
>>>> should
>>>> have done before. I'll replace the WARN_ON in vmalloc that triggers by
ernel_level2_pgt)...
I still need to compile a kernel with the patch and the old layout
but I kind of got exited by the find. At least this is tested with
the 1G/~1G layout and it comes up without vmalloc errors.
-Stefan
>From 4b9a9a45177284e29d345eb54c545bd1da718e1b Mon Sep 17 00:00:00 2001
F
On 26.08.2014 18:01, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 22, 2014 at 11:20:50AM +0200, Stefan Bader wrote:
>> On 21.08.2014 18:03, Kees Cook wrote:
>>> On Tue, Aug 12, 2014 at 2:07 PM, Konrad Rzeszutek Wilk
>>> wrote:
>>>> On Tue, Aug 12, 2014 at 11:5
On 21.08.2014 18:03, Kees Cook wrote:
> On Tue, Aug 12, 2014 at 2:07 PM, Konrad Rzeszutek Wilk
> wrote:
>> On Tue, Aug 12, 2014 at 11:53:03AM -0700, Kees Cook wrote:
>>> On Tue, Aug 12, 2014 at 11:05 AM, Stefan Bader
>>> wrote:
>>>> On 12.08.2014 19:28,
gc...
-Stefan
>
> On Tue, Aug 19, 2014 at 6:01 AM, Stefan Bader
> wrote:
>> commit a664d0f05a2ec02c8f042db536d84d15d6e19e81
>> bcache: fix crash on shutdown in passthrough mode
>>
>> added a safeguard in the shutdown case. At least while not being
>> attach
trying to
wake up the thread for that case.
Signed-off-by: Stefan Bader
---
drivers/md/bcache/writeback.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/bcache/writeback.h b/drivers/md/bcache/writeback.h
index 0a9dab1..073a042 100644
--- a/drivers/md/bcache
Commit-ID: fb21b84e7f809ef04b1e5aed5d463cf0d4866638
Gitweb: http://git.kernel.org/tip/fb21b84e7f809ef04b1e5aed5d463cf0d4866638
Author: Stefan Bader
AuthorDate: Fri, 15 Aug 2014 10:57:46 +0200
Committer: H. Peter Anvin
CommitDate: Fri, 15 Aug 2014 13:45:32 -0700
x86_32, entry: Clean up
f symmetry, change the second syscall_badsys to sysenter_badsys.
Signed-off-by: Stefan Bader
---
arch/x86/kernel/entry_32.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 47c410d..4b0e1df 100644
--- a/arch/x86/kernel/
On 12.08.2014 19:28, Kees Cook wrote:
> On Fri, Aug 8, 2014 at 7:35 AM, Stefan Bader
> wrote:
>> On 08.08.2014 14:43, David Vrabel wrote:
>>> On 08/08/14 12:20, Stefan Bader wrote:
>>>> Unfortunately I have not yet figured out why this happens, but can confir
On 08.08.2014 14:43, David Vrabel wrote:
> On 08/08/14 12:20, Stefan Bader wrote:
>> Unfortunately I have not yet figured out why this happens, but can confirm by
>> compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR
>> all
>> is ok, but with
Unfortunately I have not yet figured out why this happens, but can confirm by
compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR all
is ok, but with it enabled there are issues (actually a dom0 does not even boot
as a follow up error).
Details can be seen in [1] but basic
On 08.07.2014 15:09, Peter Zijlstra wrote:
> On Thu, Jun 12, 2014 at 03:00:17PM +0200, Stefan Bader wrote:
>> When reading from /proc/stat we allocate a large buffer to maximise
>> the chances of the results being from a single run and thus internally
>> consistent. This curr
On 25.06.2014 01:44, David Rientjes wrote:
> On Thu, 12 Jun 2014, Stefan Bader wrote:
>
>> doh, so you guys have been hit by that before. And I have missed the fact
>> that
>> single_open is special. Which makes the change for the upper limit do the
>> wrong
>&
On 12.06.2014 15:41, Heiko Carstens wrote:
> On Thu, Jun 12, 2014 at 03:00:17PM +0200, Stefan Bader wrote:
>> When reading from /proc/stat we allocate a large buffer to maximise
>> the chances of the results being from a single run and thus internally
>> consistent. This curr
sense
generally? It seemed to stop top complaining wildly for the reporter
at least.
-Stefan
---
>From a329ad61fbd26990b294f3b35a31ec80ffab35bb Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Wed, 14 May 2014 12:58:37 +0200
Subject: [PATCH] fs/stat: Reduce memory requirements for stat_open
W
On 08.04.2014 14:21, Peter Zijlstra wrote:
> On Mon, Apr 07, 2014 at 08:56:58PM +0200, Peter Zijlstra wrote:
>> On Mon, Apr 07, 2014 at 08:16:24PM +0200, Toralf Förster wrote:
>>
>>> v3.14-10353-g2b3a8fd works fine AFAICS
>>> (BTW the fix is stable material, right ?)
>>
>> I'm fairly sure its not;
On 24.03.2014 18:39, Paolo Bonzini wrote:
> Il 20/02/2014 16:50, Peter Zijlstra ha scritto:
> > >> One thing I likely should do is to reinstall the exact same laptop
> with 64bit
> > >> kernel and userspace... maybe only 64bit kernel first... and make
> > >> sure
> on my
>
On 14.02.2014 18:21, Peter Zijlstra wrote:
> On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
>> One thing I likely should do is to reinstall the exact same laptop with 64bit
>> kernel and userspace... maybe only 64bit kernel first... and make sure on my
>> si
On 14.02.2014 19:23, Stefan Bader wrote:
> On 14.02.2014 18:33, Borislav Petkov wrote:
>> On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
>>> Okaaay, I think I did what you asked. So yes, there is sse2 in the cpu
>>> info. And
>>> there is a mfe
On 14.02.2014 18:33, Borislav Petkov wrote:
> On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
>> Okaaay, I think I did what you asked. So yes, there is sse2 in the cpu info.
>> And
>> there is a mfence in the disassembly:
>
> Btw, I just realized booting
On 14.02.2014 15:47, Borislav Petkov wrote:
> On Fri, Feb 14, 2014 at 03:24:09PM +0100, Stefan Bader wrote:
>> Actually, this code just makes so much more sense if I let objdump do
>> relocation info...
>
> Ok, we're pretty sure you have an MFENCE there in resched_tas
On 14.02.2014 16:21, Borislav Petkov wrote:
> Oh, and just in case this is relatively easy to reproduce and in case we
> don't have any other idea, bisection might be another option. I'm not
> saying you should do it right away - I'm just putting it on the table...
>
> :-)
>
> :-)
>
Oh yeah, bi
On 13.02.2014 19:25, Peter Zijlstra wrote:
> On Thu, Feb 13, 2014 at 06:00:19PM +0100, Stefan Bader wrote:
>> On 12.02.2014 12:54, Peter Zijlstra wrote:
>>> On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
>>>> Something else here I run a kernel with CONF
On 13.02.2014 19:25, Peter Zijlstra wrote:
> On Thu, Feb 13, 2014 at 06:00:19PM +0100, Stefan Bader wrote:
>> On 12.02.2014 12:54, Peter Zijlstra wrote:
>>> On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
>>>> Something else here I run a kernel with CONF
On 12.02.2014 12:54, Peter Zijlstra wrote:
> On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
>> Something else here I run a kernel with CONFIG_PREEMPT not set and NR_CPUS
>> limited to 8 (for the 32bit kernel). So the default apic driver is
On 12.02.2014 11:40, Borislav Petkov wrote:
> On Wed, Feb 12, 2014 at 11:37:13AM +0100, Peter Zijlstra wrote:
>>> Another reporter also saw this on an AMD and said it could not be
>>> reproduced on
>>> the same hardware and the same software versions when using 64bit instead
>>> of 32.
>>>
>>> In
On 11.02.2014 20:45, Peter Zijlstra wrote:
> On Tue, Feb 11, 2014 at 07:34:51PM +0100, Stefan Bader wrote:
>> Hi Peter,
>>
>> I am currently looking at a weird issue that manifest itself when trying to
>> run
>> kvm enabled qemu on a i386 host (v3.13 kernel, oh
Hi Peter,
I am currently looking at a weird issue that manifest itself when trying to run
kvm enabled qemu on a i386 host (v3.13 kernel, oh and potentially important the
cpu is 64bit capable, so qemu-system-x86_64 is called). Sooner or later this
causes softlockup messages on the host. I tracked t
here? Should the platform device be removed or what would be a
good way to go forward here?
-Stefan
--
From 5eaa87a69bb40ffeec759b6e5aeec1a26bba1680 Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Wed, 29 Jan 2014 16:45:12 +
Subject: [PATCH] drm/cirrus: Ignore busy mem region when mapping
On 26.06.2013 20:37, David Miller wrote:
> From: Stefan Bader
> Date: Wed, 26 Jun 2013 10:51:36 +0200
>
>>> [ Upstream commits e5195c1f31f399289347e043d6abf3ffa80f0005 and
>>> b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 ]
> ...
>> No abjecti
On 26.06.2013 04:35, Ben Hutchings wrote:
> 3.2.48-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Stefan Bader
>
> [ Upstream commits e5195c1f31f399289347e043d6abf3ffa80f0005 and
> b423e9ae49d78ea3f53b131c8d5a60
On 08.04.2013 09:42, Jan Beulich wrote:
On 07.04.13 at 07:54, Zhenzhong Duan wrote:
>> nmi isn't supported in dom0, fallback to general all cpu backtrace code.
>
> Since when is sending NMIs not supported, and since when is this
> Dom0-specific? If you want to deal with this, you should do s
ve proposal would be to stop using UC- in the PAT
>> entirely. The memtype code could learn to emulate UC- when there's an
>> overlapping WC or WP MTRR.
>>
>> Any thoughts? Are there known errata here? Is there a good reason
>> why the kernel needs UC-? Will this be
On 08.04.2013 16:15, Borislav Petkov wrote:
> On Mon, Apr 08, 2013 at 03:10:00PM +0200, Stefan Bader wrote:
>> * that we limited the number of possible pages already to
>> * the number of pages in the large page.
>> */
>> if (address
On 08.04.2013 14:51, Borislav Petkov wrote:
> On Mon, Apr 08, 2013 at 02:28:47PM +0200, Stefan Bader wrote:
>> To enforce the PSE bit here sounds reasonably right. And also apply
>> canon_pgprot, too. GLOBAL I don't know for sure.
>
> Well sure, you don't want to fl
On 08.04.2013 13:59, Borislav Petkov wrote:
> On Mon, Apr 08, 2013 at 01:53:44PM +0200, Ingo Molnar wrote:
>>
>> * Borislav Petkov wrote:
>>
have been the source of the confusion. Remove the noop initialization
accordingly.
Signed-off-by: Andrea Arcangeli
>>>
>>> Yeah, looks g
When looking through some mm code I stumbled over one part in
arch/x86/mm/pageattr.c that looks somewhat bogus to me. Cannot
say what exactly the effects are, but maybe you do (or you could
explain to me why I am wrong :)).
commit a8aed3e0752b4beb2e37cbed6df69faae88268da
Author: Andrea Arcangeli
Ok, so how about this?
-Stefan
From 9870926d4a847e36c0f61921762fd50f1c92f75d Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Mon, 14 Jan 2013 16:17:00 +0100
Subject: [PATCH] ACPI: Check MSR valid bit before using P-state frequencies
To fix incorrect P-state frequencies which can happen on
On 01/21/2013 12:42 PM, Borislav Petkov wrote:
On Mon, Jan 21, 2013 at 12:22:18PM +, Stefan Bader wrote:
So for having the "check for sensible BIOS" in mainline I refreshed
the patch (fixed the bit test, and actually tested it this time) and
also added some hopefully sensible expl
d actually tested it this time) and also added some
hopefully sensible explanation to it (attached below).
Should I send it to acpi lists or would that have to go via an Andre?
-Stefan
From 6e2fc8291c91339123a37162382d8b08b50867ba Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Mon, 14 Jan
On 01/16/2013 11:26 AM, Jan Beulich wrote:
On 15.01.13 at 18:53, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 14, 2013 at 05:34:45PM +0100, Borislav Petkov wrote:
On Mon, Jan 14, 2013 at 04:58:54PM +0100, Stefan Bader wrote:
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi
On 14.01.2013 17:34, Borislav Petkov wrote:
> On Mon, Jan 14, 2013 at 04:58:54PM +0100, Stefan Bader wrote:
>> Starting with kernel v3.7 the following commit added a quirk
>> to obtain the real frequencies of certain AMD systems:
>>
>> commit f594065faf4f9067c2283a3
Starting with kernel v3.7 the following commit added a quirk
to obtain the real frequencies of certain AMD systems:
commit f594065faf4f9067c2283a34619fc0714e79a98d
Author: Matthew Garrett
Date: Tue Sep 4 08:28:06 2012 +
ACPI: Add fixups for AMD P-state figures
When running bare-metal,
On 18.10.2012 15:33, Luis Henriques wrote:
> On Thu, Oct 18, 2012 at 12:23:38PM +0200, Stefan Bader wrote:
>> On 18.10.2012 10:27, cwillu wrote:
>>> On Tue, Jul 24, 2012 at 8:21 AM, tip-bot for Peter Zijlstra
>>> wrote:
>>>> Commit-ID: 8323f26ce3425
ents.
>>
>> The below tries to fix it using an extra pointer which is
>> updated under the appropriate scheduler locks. Its not pretty,
>> but I can't really see another way given how all the cgroup
>> stuff works.
>>
>> Reported-and-tested-by: Stefan
On 07.09.2012 17:52, Jan Beulich wrote:
>>>> On 07.09.12 at 17:47, Stefan Bader wrote:
>> On 07.09.2012 17:44, Jan Beulich wrote:
>>> All of this still doesn't provide evidence that a plain upstream
>>> kernel is actually having any problems in the first
On 07.09.2012 17:44, Jan Beulich wrote:
>>>> On 07.09.12 at 16:22, "Justin M. Forbes" wrote:
>> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
>>>>>> On 07.09.12 at 15:21, Stefan Bader wrote:
>>>> On 07.09.2012 14:33, Jan
On 07.09.2012 14:33, Jan Beulich wrote:
>>>> On 07.09.12 at 13:40, Stefan Bader wrote:
>> When writing unsupported flags into CR4 (for some time the
>> xen_write_cr4 function would refuse to do anything at all)
>> older Xen hypervisors (and patch can potentially be i
5e8 Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Fri, 15 Jun 2012 11:54:59 +0200
Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
Older Xen hypervisors (like RHEL5 versions found to be used
on Amazon's EC2) did have a bug which would crash the domain
when trying to write
ion might be not really well written. So I am attaching a version that
tries to do better. The code change itself is the same.
-Stefan
---
From 737a5ebdd7ac1f4106cb0b0c53cc8f73b6ff1aca Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Fri, 13 Jul 2012 15:16:33 +0200
Subject: [PATCH] x86/mm: Lim
ing on the whole topic. Sorry about that. So the re-post just should
serve as a reminder as the last comment here was quite a while ago.
Stefan Bader wrote:
Avi wrote:
The fact that the check is only done on i386 and not on x86_64 may come
from one of
- an oversight - by the time x86_64
nsidered.
-Stefan
>From 1d5cc3971716a039c91abc18cb6f9bcbe5dde490 Mon Sep 17 00:00:00 2001
From: Stefan Bader
Date: Fri, 13 Jul 2012 15:16:33 +0200
Subject: [PATCH] x86/mm: Limit 2/4M size calculation to x86_32
commit 722bc6b (x86/mm: Fix the size calculation of mapping tables)
did modify the extra space calculation for mapp
I am announcing the release of the 2.6.32.59+drm33.26 longterm tree.
This tree is based on 2.6.32 and generally has all of the stable updates
applied. Except those to the DRM subsystem, which was based on 2.6.33 and
took updates from that upstream stable as long as that existed. It will
continue t
41da55dd2 upstream)
Signed-off-by: Stefan Bader
---
drivers/gpu/drm/drm_crtc.c |4
include/drm/drm_mode.h |2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 405c63b..8323fc3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/dr
On 25.07.2012 15:40, Avi Kivity wrote:
> On 07/25/2012 04:24 PM, Stefan Bader wrote:
>>>> ...
>>>> ifdef CONFIG_X86_32
>>>> /*
>>>> * Don't use a large page for the first 2/4MB of memory
>>>> * b
On 25.07.2012 14:32, Avi Kivity wrote:
> On 07/25/2012 02:14 PM, Stefan Bader wrote:
>> On 25.07.2012 12:44, Avi Kivity wrote:
>>> On 07/24/2012 06:52 PM, Cong Wang wrote:
>>>
>>>>> From 6b679d1af20656929c0e829f29eed60b0a86a74f Mon Sep 17 00:00:00 2001
>
1 - 100 of 117 matches
Mail list logo
