On Thu, Dec 17, Andrea Parri (Microsoft) wrote:
> Check that the packet is of the expected size at least, don't copy data
> past the packet.
> + if (hv_pkt_datalen(desc) < sizeof(struct vstor_packet) -
> + stor_device->vmscsi_size_delta) {
> +
Am Fri, 26 Mar 2021 01:55:41 +0900
schrieb Masahiro Yamada :
> What about drivers/net/ethernet/lantiq_etop.c ?
Nothing complained about it. I guess there is a build-bot for alpha, but none
for mips.
> I got a lot of complaints in the last trial.
Why did you get complains, instead of me?
Am Fri, 19 Mar 2021 15:32:31 +0100
schrieb Olaf Hering :
> It is a hard error if a return value is ignored.
The automated builds found only a single error, in load_em86().
Let me know if there are other reasons why the patch was rejected.
Olaf
pgpwH6ihF0muQ.pgp
Description: Digitale Signa
In preparation to build with -Werror=unused-result, use remove_arg_zero
properly.
Fixes commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
Signed-off-by: Olaf Hering
---
fs/binfmt_em86.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/binfmt_em86.c b/fs/binfmt_em86.c
Am Fri, 19 Mar 2021 15:41:44 +0100
schrieb Olaf Hering :
> FullyQualifiedDomainName
I think in the past I did asked MSFT what the host side really expects. Maybe
this time there will be an answer.
Why would the host expect a FQDN from a VM? Why would it care about DNS layout
of the netw
answered with an empty
string.
Signed-off-by: Olaf Hering
---
v2:
resend, the thread aims for success.
tools/hv/Makefile| 2 ++
tools/hv/hv_kvp_daemon.c | 69 ++--
2 files changed, 48 insertions(+), 23 deletions(-)
diff --git a/tools/hv/Make
It is a hard error if a return value is ignored.
In case the return value has no meaning, remove the attribute.
Signed-off-by: Olaf Hering
---
v2:
resend
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a28bb374663d..9b7def6db494 100644
It is a hard error if a return value is ignored.
In case the return value has no meaning, remove the attribute.
Signed-off-by: Olaf Hering
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e2c3f65c4721..c7f9acffad42 100644
--- a/Makefile
hvfb_getmem uses vzalloc, therefore vmalloc.h should be included.
Fixes commit d21987d709e807ba7bbf47044deb56a3c02e8be4 ("video: hyperv:
hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
Signed-off-by: Olaf Hering
---
drivers/video/fbdev/hyperv_fb.c | 1 +
1 file
Am Mon, 19 Oct 2020 02:58:08 +
schrieb Michael Kelley :
> I think we should take the patch.
Thanks. I just briefly looked at the code, did not understand much of it. But
it feels like the math uses the wrong input. I think its is not the 'pr_warn'
that needs changing, the 'Fixes' tag would
Am Tue, 13 Oct 2020 11:19:21 +0200
schrieb Olaf Hering :
> A message is generated every 5 minutes. Unclear why this remained unnoticed
> since at least v5.3. I have added debug to my distro kernel to see what the
> involved variable values are. More info later today.
The actu
Am Tue, 13 Oct 2020 09:17:17 +
schrieb Wei Liu :
> So ... this patch is not needed anymore?
Why? A message is generated every 5 minutes. Unclear why this remained
unnoticed since at least v5.3. I have added debug to my distro kernel to see
what the involved variable values are. More info
Catch errors which at least gcc tolerates by default:
warning: 'return' with no value, in function returning non-void [-Wreturn-type]
Signed-off-by: Olaf Hering
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index f84d7e4ca0be..965e7259e6e8
Am Thu, 8 Oct 2020 09:12:15 +0200
schrieb Olaf Hering :
> warning is logged in dmesg
Actually it is logged on the system console, depending on how logging is
configured.
Olaf
pgpdjkpjAh1xK.pgp
Description: Digitale Signatur von OpenPGP
It is not an error if a the host requests to balloon down, but the VM
refuses to do so. Without this change a warning is logged in dmesg
every five minutes.
Fixes commit b3bb97b8a49f3
Signed-off-by: Olaf Hering
---
drivers/hv/hv_balloon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Catch errors which at least gcc tolerates by default:
warning: 'return' with no value, in function returning non-void [-Wreturn-type]
Signed-off-by: Olaf Hering
---
Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Makefile b/Makefile
index f84d7e4ca0be..7b2e63e7be18 100644
No need to cast a void pointer.
Signed-off-by: Olaf Hering
---
drivers/hv/vmbus_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 910b6e90866c..187809977360 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv
On Fri, Jun 26, Joseph Salisbury wrote:
> When the kernel panics, one page worth of kmsg data is written to an allocated
> page. The Hypervisor is notified of the page address trough the MSR. This
> panic information is collected on the host. Since we are only collecting one
> page of data,
On Fri, Feb 22, Paolo Bonzini wrote:
> On 22/02/19 12:44, Thomas Gleixner wrote:
> >> The specific usecase I have is a workload within VMs that makes heavy
> >> use of TSC. The kernel is booted with 'clocksource=tsc highres=off
> >> nohz=off'
> >> because only this clocksource gives enough
Am Fri, 22 Feb 2019 12:44:39 +0100 (CET)
schrieb Thomas Gleixner :
> Whether that is accurate enough or not to make NTP happy, I can't tell, but
> it's definitely worth a try.
Thanks Thomas, I will look into the suggestions.
Olaf
pgpKvKEGb9vSF.pgp
Description: Digitale Signatur von OpenPGP
Is there a way to recalibrate the x86 TSC during a suspend/resume cycle?
While the frequency will remain the same on a Laptop, it may (or rather:
it definitly will) differ if a VM is migrated from one host to another.
The hypervisor may choose to emulate the expected TSC frequency on the
On Thu, Feb 07, lantianyu1...@gmail.com wrote:
> +++ b/drivers/iommu/Kconfig
> +config HYPERV_IOMMU
> + bool "Hyper-V x2APIC IRQ Handling"
> + depends on HYPERV
> + select IOMMU_API
> + help
Consider adding 'default HYPERV' like some other drivers already do it.
Olaf
Am Sun, 17 Sep 2017 20:54:18 -0700
schrieb k...@exchange.microsoft.com:
> This extends existing vmbus related sysfs structure to provide per-channel
> state information. This is useful when diagnosing issues with multiple
> queues in networking and storage.
> +++ b/drivers/hv/vmbus_drv.c
>
Am Sun, 17 Sep 2017 20:54:18 -0700
schrieb k...@exchange.microsoft.com:
> This extends existing vmbus related sysfs structure to provide per-channel
> state information. This is useful when diagnosing issues with multiple
> queues in networking and storage.
> +++ b/drivers/hv/vmbus_drv.c
>
From: Olaf Hering <oher...@suse.de>
Python3 changed the way how 'print' works.
Adjust the code to a syntax that is understood by python2 and python3.
Signed-off-by: Olaf Hering <oher...@suse.de>
---
tools/hv/lsvmbus | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
From: Olaf Hering
Python3 changed the way how 'print' works.
Adjust the code to a syntax that is understood by python2 and python3.
Signed-off-by: Olaf Hering
---
tools/hv/lsvmbus | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/hv/lsvmbus b/tools/hv
Python3 changed the way how 'print' works.
Adjust the code to a syntax that is understood by python2 and python3.
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
v2:
correct author
tools/hv/lsvmbus | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/to
Python3 changed the way how 'print' works.
Adjust the code to a syntax that is understood by python2 and python3.
Signed-off-by: Olaf Hering
---
v2:
correct author
tools/hv/lsvmbus | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/hv/lsvmbus b/tools/hv
The usage of strchr requires inclusion of string.h.
Fixes: 0c38cda64aec ("tools: hv: remove unnecessary header files and netlink
related code")
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/hv/hv_fcopy_daemon.c | 1 +
1 file changed, 1 insertion(+)
diff
The usage of strchr requires inclusion of string.h.
Fixes: 0c38cda64aec ("tools: hv: remove unnecessary header files and netlink
related code")
Signed-off-by: Olaf Hering
---
tools/hv/hv_fcopy_daemon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/hv/hv_fcopy_daemon.c
On Fri, Dec 08, Eduardo Otubo wrote:
> tools/hv/hv_set_ifconfig.sh | 45
> +++--
> 1 file changed, 43 insertions(+), 2 deletions(-)
> +# let's wait for 3 minutes
Was this codepath runtime tested?
Last time this came up, the conclusion was that
On Fri, Dec 08, Eduardo Otubo wrote:
> tools/hv/hv_set_ifconfig.sh | 45
> +++--
> 1 file changed, 43 insertions(+), 2 deletions(-)
> +# let's wait for 3 minutes
Was this codepath runtime tested?
Last time this came up, the conclusion was that
On Tue, Sep 05, KY Srinivasan wrote:
> Were you planning on sending a patch for this.
No, not yet. I dont know how SA_RESTART works.
Olaf
signature.asc
Description: PGP signature
On Tue, Sep 05, KY Srinivasan wrote:
> Were you planning on sending a patch for this.
No, not yet. I dont know how SA_RESTART works.
Olaf
signature.asc
Description: PGP signature
On Mon, Aug 28, Eduardo Otubo wrote:
> +sleep 30s;
Was this runtime tested?
Once this sleep(1) is done, HV_UTIL_TIMEOUT kicks in and the daemon dies.
Olaf
signature.asc
Description: PGP signature
On Mon, Aug 28, Eduardo Otubo wrote:
> +sleep 30s;
Was this runtime tested?
Once this sleep(1) is done, HV_UTIL_TIMEOUT kicks in and the daemon dies.
Olaf
signature.asc
Description: PGP signature
On Fri, Aug 25, Vitaly Kuznetsov wrote:
> Shall we request SA_RESTART with sigaction() in all three daemons instead?
If that works better, probably yes.
Olaf
signature.asc
Description: PGP signature
On Fri, Aug 25, Vitaly Kuznetsov wrote:
> Shall we request SA_RESTART with sigaction() in all three daemons instead?
If that works better, probably yes.
Olaf
signature.asc
Description: PGP signature
slightly less than expected.
Fix this by restoring the expected buffer size in case of WRITE_TO_FILE.
Fixes: c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport")
Fixes: 3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon")
Signed-off-by: Olaf He
slightly less than expected.
Fix this by restoring the expected buffer size in case of WRITE_TO_FILE.
Fixes: c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport")
Fixes: 3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon")
Signed-off-by: Olaf Her
If strace attaches to the daemon pread returns with EINTR, and the
process exits. Catch this case and continue with the next iteration.
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/hv/hv_fcopy_daemon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/hv/hv_fcopy_daem
If strace attaches to the daemon pread returns with EINTR, and the
process exits. Catch this case and continue with the next iteration.
Signed-off-by: Olaf Hering
---
tools/hv/hv_fcopy_daemon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv
members as
needed. This also gives the correct size for the buffer (~6K instead of 64K).
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/hv/hv_fcopy_daemon.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/tools/hv/hv_fcopy_daemon.c b/to
members as
needed. This also gives the correct size for the buffer (~6K instead of 64K).
Signed-off-by: Olaf Hering
---
tools/hv/hv_fcopy_daemon.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv
Increase buffer size so that "_{-INT_MAX}" will fit.
Spotted by the gcc7 snprintf checker.
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/hv/hv_kvp_daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kv
Increase buffer size so that "_{-INT_MAX}" will fit.
Spotted by the gcc7 snprintf checker.
Signed-off-by: Olaf Hering
---
tools/hv/hv_kvp_daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 88
On Thu, Dec 01, Olaf Hering wrote:
> On Wed, Nov 16, Olaf Hering wrote:
> > During boot into a current openSUSE Tumbleweed 20161108 this laptop
> > starts to hang sometimes with 4.8.x. Today I was able to catch this
> > crash in __wake_up_common caused by i9
On Thu, Dec 01, Olaf Hering wrote:
> On Wed, Nov 16, Olaf Hering wrote:
> > During boot into a current openSUSE Tumbleweed 20161108 this laptop
> > starts to hang sometimes with 4.8.x. Today I was able to catch this
> > crash in __wake_up_common caused by i9
On Fri, Jan 13, Vitaly Kuznetsov wrote:
> + hv_ptp_clock = ptp_clock_register(_hyperv_info, NULL);
> + if (IS_ERR(hv_ptp_clock)) {
Should that be IS_ERR_OR_NULL to catch "!IS_REACHABLE(CONFIG_PTP_1588_CLOCK)"?
Olaf
signature.asc
Description: PGP signature
On Fri, Jan 13, Vitaly Kuznetsov wrote:
> + hv_ptp_clock = ptp_clock_register(_hyperv_info, NULL);
> + if (IS_ERR(hv_ptp_clock)) {
Should that be IS_ERR_OR_NULL to catch "!IS_REACHABLE(CONFIG_PTP_1588_CLOCK)"?
Olaf
signature.asc
Description: PGP signature
On Tue, Dec 20, Roman Kagan wrote:
Reverting commit 22356585712d ("staging: hv: use sync_bitops when
interacting with the hypervisor") is save because ...
> - sync_set_bit(channel->monitor_bit,
> + set_bit(channel->monitor_bit,
Olaf
signature.asc
Description: PGP
On Tue, Dec 20, Roman Kagan wrote:
Reverting commit 22356585712d ("staging: hv: use sync_bitops when
interacting with the hypervisor") is save because ...
> - sync_set_bit(channel->monitor_bit,
> + set_bit(channel->monitor_bit,
Olaf
signature.asc
Description: PGP
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> -> K. Y., but these words were written before I implemented
> vmbus_wait_for_unload(), to me they just explain how we read messages.
Another question for KY:
In my testing, while busy-looping in vmbus_wait_for_unload, I see a few
"message_type==1,
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> -> K. Y., but these words were written before I implemented
> vmbus_wait_for_unload(), to me they just explain how we read messages.
Another question for KY:
In my testing, while busy-looping in vmbus_wait_for_unload, I see a few
"message_type==1,
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> vmbus_wait_for_unload() may be receiving a message (not necessarily the
> CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same
> CPU it runs and in this case wrmsrl() makes sense. In other cases it
> does nothing (neither good nor bad).
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> vmbus_wait_for_unload() may be receiving a message (not necessarily the
> CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same
> CPU it runs and in this case wrmsrl() makes sense. In other cases it
> does nothing (neither good nor bad).
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> We actually need to read the reply and empty the message slot to make
> unload happen. And reading on a different CPU may not work, see:
>
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/097330.html
Does the following
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> We actually need to read the reply and empty the message slot to make
> unload happen. And reading on a different CPU may not work, see:
>
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/097330.html
Does the following
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> I see a number of minor but at least one major issue against such move:
> At least for some Hyper-V versions (2012R2 for example)
> CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent
> CHANNELMSG_REQUESTOFFERS and on kdump we may not
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> I see a number of minor but at least one major issue against such move:
> At least for some Hyper-V versions (2012R2 for example)
> CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent
> CHANNELMSG_REQUESTOFFERS and on kdump we may not
On Thu, Dec 15, Olaf Hering wrote:
> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>
> > I see a number of minor but at least one major issue against such move:
> > At least for some Hyper-V versions (2012R2 for example)
> > CHANNELMSG_UNLOAD_RESPONSE is delivered to the
On Thu, Dec 15, Olaf Hering wrote:
> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>
> > I see a number of minor but at least one major issue against such move:
> > At least for some Hyper-V versions (2012R2 for example)
> > CHANNELMSG_UNLOAD_RESPONSE is delivered to the
On Mon, Dec 12, Olaf Hering wrote:
> On Mon, Dec 12, Theodore Ts'o wrote:
>
> > What was going on at the time of the crash, and can you reproduce this?
>
> Its the 'rm -rf $dir/$oldbackup.N' at the end of each rsnapshot run.
Also, the system was otherwise idle during th
On Mon, Dec 12, Theodore Ts'o wrote:
> What was going on at the time of the crash, and can you reproduce this?
Its the 'rm -rf $dir/$oldbackup.N' at the end of each rsnapshot run.
I will try to reproduce it, see if it happens again during the hourly
rsnapshot runs. So far I have not seen it with
On Mon, Dec 12, Olaf Hering wrote:
> On Mon, Dec 12, Theodore Ts'o wrote:
>
> > What was going on at the time of the crash, and can you reproduce this?
>
> Its the 'rm -rf $dir/$oldbackup.N' at the end of each rsnapshot run.
Also, the system was otherwise idle during th
On Mon, Dec 12, Theodore Ts'o wrote:
> What was going on at the time of the crash, and can you reproduce this?
Its the 'rm -rf $dir/$oldbackup.N' at the end of each rsnapshot run.
I will try to reproduce it, see if it happens again during the hourly
rsnapshot runs. So far I have not seen it with
On Mon, Dec 12, Olaf Hering wrote:
> [197064.401309] RIP: 0010:[] []
> __d_lookup_rcu+0x67/0x180
... and umount is not happy after that, which I think is expected:
root@probook:~ # umount -v /BACKUP_OLH_1T ; dmsetup remove
luks-feaf408d-3257-4850-b597-bbca1dc651df ; sync ; bl
On Mon, Dec 12, Olaf Hering wrote:
> [197064.401309] RIP: 0010:[] []
> __d_lookup_rcu+0x67/0x180
... and umount is not happy after that, which I think is expected:
root@probook:~ # umount -v /BACKUP_OLH_1T ; dmsetup remove
luks-feaf408d-3257-4850-b597-bbca1dc651df ; sync ; bl
This crash happend during rsnapshot cleanup, full dmesg below:
Dec 11 17:15:02 probook rsnapshot-backup-scripts.hourly.sh[3244]: claimed
rsnapshot_pid_lock
Dec 11 17:15:02 probook rsnapshot-backup-scripts.hourly.sh[3247]: running hourly
...
[197064.399173] general protection fault: [#1]
This crash happend during rsnapshot cleanup, full dmesg below:
Dec 11 17:15:02 probook rsnapshot-backup-scripts.hourly.sh[3244]: claimed
rsnapshot_pid_lock
Dec 11 17:15:02 probook rsnapshot-backup-scripts.hourly.sh[3247]: running hourly
...
[197064.399173] general protection fault: [#1]
On Wed, Dec 07, KY Srinivasan wrote:
> May be a better solution might be to have a new mechanism to indicate
> to the host that all state of the previous incarnation of the kernel
> needs to be cleaned up. This will be close to what we have on
> hardware.
That would be cool, but until this
On Wed, Dec 07, KY Srinivasan wrote:
> May be a better solution might be to have a new mechanism to indicate
> to the host that all state of the previous incarnation of the kernel
> needs to be cleaned up. This will be close to what we have on
> hardware.
That would be cool, but until this
On Wed, Dec 07, KY Srinivasan wrote:
> Is there a mechanism for stashing away state that can be retrieved in
> the context of the execed kernel.
I have to find out. To simplify things the new approach may only be used
in the kdump case, which already passes various info in cmdline. Most
likely
On Wed, Dec 07, KY Srinivasan wrote:
> Is there a mechanism for stashing away state that can be retrieved in
> the context of the execed kernel.
I have to find out. To simplify things the new approach may only be used
in the kdump case, which already passes various info in cmdline. Most
likely
Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan :
>Yes; I had played with this approach a while ago. The issue is that the
>host knows about a
>bunch of in memory state that will be different in the kexec kernel.
>For instance if we did all
>the cleanup as part of the
Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan :
>Yes; I had played with this approach a while ago. The issue is that the
>host knows about a
>bunch of in memory state that will be different in the kexec kernel.
>For instance if we did all
>the cleanup as part of the boot sequence, we
KY,
if a hyperv VM crashes alot of work must be done to prepare the
environment for the kdump kernel. This approach is different compared to
all the other VM types, or baremetal. Since the just crashed kernel is
per definition unreliable all that work should be done within the kdump
kernel
KY,
if a hyperv VM crashes alot of work must be done to prepare the
environment for the kdump kernel. This approach is different compared to
all the other VM types, or baremetal. Since the just crashed kernel is
per definition unreliable all that work should be done within the kdump
kernel
On Wed, Nov 16, Olaf Hering wrote:
> During boot into a current openSUSE Tumbleweed 20161108 this laptop
> starts to hang sometimes with 4.8.x. Today I was able to catch this
> crash in __wake_up_common caused by i915 or drm or whatever:
>
> ...
> [ 69.851635] BUG: unabl
On Wed, Nov 16, Olaf Hering wrote:
> During boot into a current openSUSE Tumbleweed 20161108 this laptop
> starts to hang sometimes with 4.8.x. Today I was able to catch this
> crash in __wake_up_common caused by i915 or drm or whatever:
>
> ...
> [ 69.851635] BUG: unabl
On Mon, Nov 21, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
Tested-by: Olaf Hering <o...@aepfle.de>
This should go
On Mon, Nov 21, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
Tested-by: Olaf Hering
This should go to stable as well.
O
On Thu, Nov 17, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
Thanks, this works for me in 4.4:
Tested-by: Olaf Hering <
On Thu, Nov 17, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
Thanks, this works for me in 4.4:
Tested-by: Olaf Hering
O
On Thu, Nov 17, Boris Ostrovsky wrote:
> On 11/17/2016 06:28 AM, Olaf Hering wrote:
> > ERROR: "__mpol_dup" [drivers/xen/xen-gntdev.ko] undefined!
> > ERROR: "get_task_policy" [drivers/xen/xen-gntdev.ko] undefined!
> I just built 4.4.11 with this patc
On Thu, Nov 17, Boris Ostrovsky wrote:
> On 11/17/2016 06:28 AM, Olaf Hering wrote:
> > ERROR: "__mpol_dup" [drivers/xen/xen-gntdev.ko] undefined!
> > ERROR: "get_task_policy" [drivers/xen/xen-gntdev.ko] undefined!
> I just built 4.4.11 with this patc
On Wed, Nov 16, Boris Ostrovsky wrote:
> Unfortunately I haven't been able to trigger NUMA balancing
> so while I tested this in general I am not sure I actually
> exercised the code path.
Thanks for the patch!
Would be nice to actually test the code path which caused the initial
addition of
On Wed, Nov 16, Boris Ostrovsky wrote:
> Unfortunately I haven't been able to trigger NUMA balancing
> so while I tested this in general I am not sure I actually
> exercised the code path.
Thanks for the patch!
Would be nice to actually test the code path which caused the initial
addition of
During boot into a current openSUSE Tumbleweed 20161108 this laptop
starts to hang sometimes with 4.8.x. Today I was able to catch this
crash in __wake_up_common caused by i915 or drm or whatever:
...
[ 69.851635] BUG: unable to handle kernel NULL pointer dereference at
(null)
[
During boot into a current openSUSE Tumbleweed 20161108 this laptop
starts to hang sometimes with 4.8.x. Today I was able to catch this
crash in __wake_up_common caused by i915 or drm or whatever:
...
[ 69.851635] BUG: unable to handle kernel NULL pointer dereference at
(null)
[
On Thu, Nov 10, Boris Ostrovsky wrote:
> Are you sure it's this patch that causes the failure?
>
> I commented out '| VM_IO' and still unable to boot with this option.
Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:
+++ b/drivers/xen/gntdev.c
@@ -804,7 +804,7 @@ static
On Thu, Nov 10, Boris Ostrovsky wrote:
> Are you sure it's this patch that causes the failure?
>
> I commented out '| VM_IO' and still unable to boot with this option.
Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:
+++ b/drivers/xen/gntdev.c
@@ -804,7 +804,7 @@ static
On Thu, Nov 10, Boris Ostrovsky wrote:
> Is this something new? Because this patch has been there for a year.
It was just tested now, cycling through all the combinations for a
disk=[]. Removing "direct-is-save" will use different code paths and the
error is not seen.
Olaf
signature.asc
On Thu, Nov 10, Boris Ostrovsky wrote:
> Is this something new? Because this patch has been there for a year.
It was just tested now, cycling through all the combinations for a
disk=[]. Removing "direct-is-save" will use different code paths and the
error is not seen.
Olaf
signature.asc
On Tue, Nov 10, Boris Ostrovsky wrote:
> Doing so will cause the grant to be unmapped and then, during
> fault handling, the fault to be mistakenly treated as NUMA hint
> fault.
>
> In addition, even if those maps could partcipate in NUMA
> balancing, it wouldn't provide any benefit since we are
On Tue, Nov 10, Boris Ostrovsky wrote:
> Doing so will cause the grant to be unmapped and then, during
> fault handling, the fault to be mistakenly treated as NUMA hint
> fault.
>
> In addition, even if those maps could partcipate in NUMA
> balancing, it wouldn't provide any benefit since we are
On Fri, Sep 09, k...@exchange.microsoft.com wrote:
> + * This check is safe since we are executing in the
> + * interrupt context and time synch messages arre always
Typo.
Olaf
signature.asc
Description: PGP signature
On Fri, Sep 09, k...@exchange.microsoft.com wrote:
> + * This check is safe since we are executing in the
> + * interrupt context and time synch messages arre always
Typo.
Olaf
signature.asc
Description: PGP signature
On Tue, Sep 13, Alex Ng (LIS) wrote:
> > On Thu, Sep 08, k...@exchange.microsoft.com wrote:
> > Perhaps a better approach would be to list the known existing hosts and use
> > the new protocol for upcoming, unknown hosts via 'default:'.
> This is a good idea. I will create another patch that
On Tue, Sep 13, Alex Ng (LIS) wrote:
> > On Thu, Sep 08, k...@exchange.microsoft.com wrote:
> > Perhaps a better approach would be to list the known existing hosts and use
> > the new protocol for upcoming, unknown hosts via 'default:'.
> This is a good idea. I will create another patch that
1 - 100 of 1191 matches
Mail list logo