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
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
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
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
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
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
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
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 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
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 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
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 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 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
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
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 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
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
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
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
Borislav Petkov wrote:
> On Sat, Feb 16, 2008 at 04:24:01PM +0100, Bartlomiej Zolnierkiewicz wrote:
>> Hi,
>>
>> On Saturday 16 February 2008, Borislav Petkov wrote:
>>> On Fri, Feb 15, 2008 at 02:53:27PM -0500, Stefan Bader wrote:
>>>> Hello Borislav,
&
I am announcing the release of the 2.6.32.59+drm33.25 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
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
>>> From: Stefan Bader
>>> Date: Fri, 13 Jul 2012 15:16:33 +0200
>>> Subject: [PATCH] x86
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
>
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/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
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
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 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
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
Hi,
I know you are surely overworked, but I am not sure who else may know
enough about this
buffer_head/page cache stuff... Feel free to ingore this if you havn't got
the time.
What I try to do:
Adding multipath support to the LVM. One part of this is to get informed
whenever an IO
completes
Hi,
I'd like to hook into the end_io reporting chain by replacing the b_end_io
function pointer by an own end_io
function that restores the original values and calls the previous end_io
function after io.
Unfortunatly if the previous function was end_buffer_io_async it unlocks
the bh->b_page
Hi,
I ran into some problems with buffer.c trying to unlock a page of async io
buffer heads more
than once.
IMHO end_buffer_io_async() shouldn't rely on the value of b_end_io to
decide if the whole
page can be unlocked. It would make it easier for other layers (well
remappers like md or
lvm) t
Chris Mason <[EMAIL PROTECTED]>
06/21/01 08:20 PM
Please respond to Chris Mason
To: Andrea Arcangeli <[EMAIL PROTECTED]>, Linus Torvalds
<[EMAIL PROTECTED]>
cc: Stefan Bader/Germany/IBM@IBMDE,
[EMAIL PROTECTED]
Subject:Re: corre
Hi,
Please respond to Christoph Biardzki <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject:Storage - redundant path failover / failback - quo vadis
linux?
>I was investigating redundant path failover with FibreChannel disk
devices
>during the last weeks. The idea is to use a
> 2007/5/25, Neil Brown <[EMAIL PROTECTED]>:
> BIO_RW_FAILFAST: means low-level driver shouldn't do much (or no)
> error recovery. Mainly used by mutlipath targets to avoid long SCSI
> recovery. This should just be propagated when passing requests on.
Is it "much" or "no"?
Would it be reasonable
2007/5/28, Alasdair G Kergon <[EMAIL PROTECTED]>:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
> 1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
The device-mapper position has always been that we require
> a zero-length BIO_RW_BARRIER
(i.e. containing no data to
The order that these are expected by the filesystem to hit stable
storage are:
1. block 4 and 10 on stable storage in any order
2. barrier block X on stable storage
3. block 5 and 20 on stable storage in any order
The point I'm trying to make is that in XFS, block 5 and 20 cannot
be allowed to
> in-flight I/O to go to zero?
Something like that is needed for some dm targets to support barriers.
(We needn't always wait for *all* in-flight I/O.)
When faced with -EOPNOTSUP, do all callers fall back to a sync in
the places a barrier would have been used, or are there any more
sophisticated
2007/5/30, Phillip Susi <[EMAIL PROTECTED]>:
Stefan Bader wrote:
>
> Since drive a supports barrier request we don't get -EOPNOTSUPP but
> the request with block y might get written before block x since the
> disk are independent. I guess the chances of this are quite low
chronous request. I don't
know whether there are more uses to it but this at least causes queues
to be flushed immediately instead of waiting for more requests for a
short time. Should also just be passed on. Otherwise performance gets
poor since something above will rather wait for the current
r
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 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 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
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. :)
>>
>>
6b679d1af20656929c0e829f29eed60b0a86a74f 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 mapping tables
On 07/13/2012 11:12 AM, Yinghai Lu wrote:
On Fri, Jul 13, 2012 at 6:41 AM, Stefan Bader
wrote:
I was bisecting a problem on 64bit where any attempt to cause a crash kernel to
boot would hang. The bisect ended up on commit 722bc6b (x86/mm: Fix the size
calculation of mapping tables) and somehow
On 07/13/2012 06:41 AM, Stefan Bader wrote:
I was bisecting a problem on 64bit where any attempt to cause a crash kernel to
boot would hang. The bisect ended up on commit 722bc6b (x86/mm: Fix the size
calculation of mapping tables) and somehow, looking at the calling function and
the ranges
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
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
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 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 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 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 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 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 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 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 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 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
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 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
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
>&
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 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,
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
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 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
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
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
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
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 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: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:
>
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 +-
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.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
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
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 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 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 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 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
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 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
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 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
>>
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
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.
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); }
>>>
>>>
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
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
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 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 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:
>>>>
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 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
1 - 100 of 117 matches
Mail list logo
