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
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)
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: correction: fs/buffer.c
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
pet...@infradead.org wrote:
Commit-ID: 8323f26ce3425460769605a6aece7a174edaa7d1
Gitweb
locks. Its not pretty,
but I can't really see another way given how all the cgroup
stuff works.
Reported-and-tested-by: Stefan Bader stefan.ba...@canonical.com
Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl
Link: http://lkml.kernel.org/r/1340364965.18025.71.camel@twins
Signed-off
6b679d1af20656929c0e829f29eed60b0a86a74f Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
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
On 07/13/2012 11:12 AM, Yinghai Lu wrote:
On Fri, Jul 13, 2012 at 6:41 AM, Stefan Bader
stefan.ba...@canonical.com 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
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
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
On 08.04.2013 13:59, Borislav Petkov wrote:
On Mon, Apr 08, 2013 at 01:53:44PM +0200, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de wrote:
have been the source of the confusion. Remove the noop initialization
accordingly.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
Yeah,
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 flush those from the TLB if it is kernel
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 == (address pmask) cpa-numpages
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 stefan.ba...@canonical.com
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 explanation
Ok, so how about this?
-Stefan
From 9870926d4a847e36c0f61921762fd50f1c92f75d Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
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
On 01/16/2013 11:26 AM, Jan Beulich wrote:
On 15.01.13 at 18:53, Konrad Rzeszutek Wilk konrad.w...@oracle.com 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
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 stefan.ba...@canonical.com
Date: Fri, 13 Jul 2012 15:16:33 +0200
Subject: [PATCH] x86/mm
Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
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
On 07.09.2012 14:33, Jan Beulich wrote:
On 07.09.12 at 13:40, Stefan Bader stefan.ba...@canonical.com 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 improved
On 07.09.2012 17:44, Jan Beulich wrote:
On 07.09.12 at 16:22, Justin M. Forbes jmfor...@linuxtx.org wrote:
On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
On 07.09.12 at 15:21, Stefan Bader stefan.ba...@canonical.com wrote:
On 07.09.2012 14:33, Jan Beulich wrote:
On 07.09.12
On 07.09.2012 17:52, Jan Beulich wrote:
On 07.09.12 at 17:47, Stefan Bader stefan.ba...@canonical.com 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 place. Further,
if you say
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
* because there are often fixed size MTRRs in there
* and overlapping MTRRs into large
Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
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 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 stefan.ba...@canonical.com 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
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
(cherry-picked from commit a5cd335165e31db9dbab636fd29895d41da55dd2 upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
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
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 worked on a problem with an DVD driver (model=Optiarc
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
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 stefan.ba...@canonical.com
Date: Fri, 13 Jul 2012 15:16:33 +0200
Subject: [PATCH] x86/mm: Limit 2/4M size calculation
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
From: Stefan Bader stefan.ba...@canonical.com
Date: Fri
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 m...@redhat.com
Date: Tue Sep 4 08:28:06 2012 +
ACPI: Add fixups for AMD P-state figures
When
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 f594065faf4f9067c2283a34619fc0714e79a98d
Author: Matthew
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 since
at some point
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
request/bio to complete instead of sending more.
Stefan Bader
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 to use
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
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 used.
Since
default_send_IPI_mask_logical
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 CONFIG_PREEMPT not set and NR_CPUS
limited
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 CONFIG_PREEMPT not set and NR_CPUS
limited
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, bisection
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_task but can
you confirm it please
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 the kernel in the guest was a dumb
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 mfence in the disassembly:
Btw, I just realized
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
side that this does not show up
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
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 and potentially important
the
cpu is 64bit
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 my case on a
-? Will this be such a big can of worms that I
should just hope there's an available MTRR?
Stefan Bader (CC-ed here) was looking in making a black-box type
code wherein for any types but WC it would lookup in the PAT index
the right bit and provide that for the page_attr_set functions.
If I
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 stefan.ba...@canonical.com
[ Upstream commits e5195c1f31f399289347e043d6abf3ffa80f0005
On 26.06.2013 20:37, David Miller wrote:
From: Stefan Bader stefan.ba...@canonical.com
Date: Wed, 26 Jun 2013 10:51:36 +0200
[ Upstream commits e5195c1f31f399289347e043d6abf3ffa80f0005 and
b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 ]
...
No abjection, just make sure that
commit
On 08.04.2013 09:42, Jan Beulich wrote:
On 07.04.13 at 07:54, Zhenzhong Duan zhenzhong.d...@oracle.com 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
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 stefan.ba...@canonical.com
Date: Wed, 14 May 2014 12:58:37 +0200
Subject: [PATCH] fs/stat: Reduce memory
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 currently is sized at 128
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 stefan.ba...@canonical.com
Date: Wed, 29 Jan 2014 16:45:12 +
Subject: [PATCH] drm/cirrus: Ignore
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
side that this does not show up on
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; its a rather
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
thing. While long-term it sounds like
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 currently is sized at 128
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
konrad.w...@oracle.com wrote:
On Tue, Aug 12, 2014 at 11:53:03AM -0700, Kees Cook wrote
...
-Stefan
On Tue, Aug 19, 2014 at 6:01 AM, Stefan Bader
stefan.ba...@canonical.com wrote:
commit a664d0f05a2ec02c8f042db536d84d15d6e19e81
bcache: fix crash on shutdown in passthrough mode
added a safeguard in the shutdown case. At least while not being
attached it is also possible
On 21.08.2014 18:03, Kees Cook wrote:
On Tue, Aug 12, 2014 at 2:07 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com 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
stefan.ba...@canonical.com wrote:
On 12.08.2014 19:28, Kees
On 12.08.2014 19:28, Kees Cook wrote:
On Fri, Aug 8, 2014 at 7:35 AM, Stefan Bader stefan.ba...@canonical.com
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 confirm
by
compiling
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
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 it enabled there are issues (actually
, change the second syscall_badsys to sysenter_badsys.
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
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
trying to
wake up the thread for that case.
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
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
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 fixmap that is compile
time set (level2_fixmap_pgt[506
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
From: Stefan Bader stefan.ba...@canonical.com
Date: Thu, 28 Aug 2014 19:17:00 +0200
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 a
panic
and at least get a crash dump of that situation
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 in vmalloc that triggers by a
panic
and at least get
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
should
have done before. I'll replace the WARN_ON
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:
x86/xen: fix 64-bit PV guest kernel page
[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 stefan.ba...@canonical.com
Cc: sta...@vger.kernel.org
---
arch/x86/xen/mmu.c | 26 +-
1 file changed, 17
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 skb fragment
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 set
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.
Hi,
AFAIK in this scenario your skb frag is wrong. The page pointer should
point
get pushed.
-Stefan
On Tue, Aug 19, 2014 at 6:01 AM, Stefan Bader
stefan.ba...@canonical.com wrote:
commit a664d0f05a2ec02c8f042db536d84d15d6e19e81
bcache: fix crash on shutdown in passthrough mode
added a safeguard in the shutdown case. At least while not being
attached it is also
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 array,
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
guest
tries to send a packet which constitues more than
Gleixner t...@linutronix.de
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/kernel/acpi/boot.c | 23 +++---
arch/x86/pci/xen.c | 47 -
2 files changed, 12 insertions(+), 58 deletions(-)
diff --git a/arch/x86
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:
Hi Thomas,
This patch set includes three hotfixes related Xen IRQ
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 BDF, 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:
On 05.02.2015 21:07, Sander Eikelenboom wrote:
Tuesday, January 20, 2015
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 includes three hotfixes related Xen IRQ for v3.19.
Sorry for the long delay to get
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); }
- min = 0; + min = VM_EXIT_SAVE_DEBUG_CONTROLS; #ifdef
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. :)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
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
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. :)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
...@ucw.cz
Cc: Bjorn Helgaas bhelg...@google.com
Link:
http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang@linux.intel.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
Signed-off-by: Greg Kroah-Hartman gre
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 stefan.ba...@canonical.com
Date: Mon, 18 Aug 2014 20:00:13 +0200
Subject
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 <stefan.ba...@canonical.com>
Date: Tue, 10 May 2
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 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
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 Ba
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 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
1 - 100 of 222 matches
Mail list logo
