Re: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

2017-03-28 Thread Joseph Salisbury 
On 03/27/2017 06:14 PM, Stephen Hemminger wrote:
> Are you sure the real problem is not the one fixed by this commit?
>
> commit f1c635b439a5c01776fe3a25b1e2dc546ea82e6f
> Author: Stephen Hemminger <step...@networkplumber.org>
> Date:   Tue Mar 7 09:15:53 2017 -0800
>
> scsi: storvsc: Workaround for virtual DVD SCSI version
> 
> Hyper-V host emulation of SCSI for virtual DVD device reports SCSI
> version 0 (UNKNOWN) but is still capable of supporting REPORTLUN.
> 
> Without this patch, a GEN2 Linux guest on Hyper-V will not boot 4.11
> successfully with virtual DVD ROM device. What happens is that the SCSI
> scan process falls back to doing sequential probing by INQUIRY.  But the
> storvsc driver has a previous workaround that masks/blocks all errors
> reports from INQUIRY (or MODE_SENSE) commands.  This workaround causes
> the scan to then populate a full set of bogus LUN's on the target and
> then sends kernel spinning off into a death spiral doing block reads on
> the non-existent LUNs.
> 
> By setting the correct blacklist flags, the target with the DVD device
> is scanned with REPORTLUN and that works correctly.
> 
> Patch needs to go in current 4.11, it is safe but not necessary in older
> kernels.
> 
> Signed-off-by: Stephen Hemminger <sthem...@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <k...@microsoft.com>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
> Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
>
> -Original Message-
> From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] 
> Sent: Monday, March 27, 2017 1:22 PM
> To: Long Li <lon...@microsoft.com>
> Cc: KY Srinivasan <k...@microsoft.com>; Martin K. Petersen 
> <martin.peter...@oracle.com>; Haiyang Zhang <haiya...@microsoft.com>; Stephen 
> Hemminger <sthem...@microsoft.com>; j...@linux.vnet.ibm.com; 
> de...@linuxdriverproject.org; linux-scsi <linux-s...@vger.kernel.org>; LKML 
> <linux-ker...@vger.kernel.org>; sta...@vger.kernel.org; Greg KH 
> <gre...@linuxfoundation.org>
> Subject: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] 
> scsi: storvsc: properly set residual data length on errors
>
> Hi Long Li,
>
> A kernel bug report was opened against Ubuntu [0].  After a kernel
> bisect, it was found that reverting the following commit resolved this bug:
>
> commit 40630f462824ee24bc00d692865c86c3828094e0
> Author: Long Li <lon...@microsoft.com>
> Date:   Wed Dec 14 18:46:03 2016 -0800
>
> scsi: storvsc: properly set residual data length on errors
>
>
> The regression was introduced in mainline as of v4.11-rc1.  It was also
> cc'd to stable and has landed in v3.12.y, v4.4.y, v4.9.y and v4.10.y.
>
>
> This regression seems pretty severe since it's preventing virtual
> machines from booting.  It's affecting a couple of users so far.  I was
> hoping to get your feedback, since you are the patch author.  Do you
> think gathering any additional data will help diagnose this issue, or
> would it be best to submit a revert request?
>
>
> Thanks,
>
> Joe
>
>
> [0] http://pad.lv/1674635
>
>
Hi Stephen,


Thanks again for pointing out commit
f1c635b439a5c01776fe3a25b1e2dc546ea82e6f.  It does indeed fix the bug. 
I noticed the commit was not cc'd to stable.  Would it be possible to do
that?


Thanks,


Joe


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

2017-03-27 Thread Joseph Salisbury 
On 03/27/2017 06:14 PM, Stephen Hemminger wrote:
> Are you sure the real problem is not the one fixed by this commit?
>
> commit f1c635b439a5c01776fe3a25b1e2dc546ea82e6f
> Author: Stephen Hemminger <step...@networkplumber.org>
> Date:   Tue Mar 7 09:15:53 2017 -0800
>
> scsi: storvsc: Workaround for virtual DVD SCSI version
> 
> Hyper-V host emulation of SCSI for virtual DVD device reports SCSI
> version 0 (UNKNOWN) but is still capable of supporting REPORTLUN.
> 
> Without this patch, a GEN2 Linux guest on Hyper-V will not boot 4.11
> successfully with virtual DVD ROM device. What happens is that the SCSI
> scan process falls back to doing sequential probing by INQUIRY.  But the
> storvsc driver has a previous workaround that masks/blocks all errors
> reports from INQUIRY (or MODE_SENSE) commands.  This workaround causes
> the scan to then populate a full set of bogus LUN's on the target and
> then sends kernel spinning off into a death spiral doing block reads on
> the non-existent LUNs.
> 
> By setting the correct blacklist flags, the target with the DVD device
> is scanned with REPORTLUN and that works correctly.
> 
> Patch needs to go in current 4.11, it is safe but not necessary in older
> kernels.
> 
> Signed-off-by: Stephen Hemminger <sthem...@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <k...@microsoft.com>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
> Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
>
> -Original Message-
> From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] 
> Sent: Monday, March 27, 2017 1:22 PM
> To: Long Li <lon...@microsoft.com>
> Cc: KY Srinivasan <k...@microsoft.com>; Martin K. Petersen 
> <martin.peter...@oracle.com>; Haiyang Zhang <haiya...@microsoft.com>; Stephen 
> Hemminger <sthem...@microsoft.com>; j...@linux.vnet.ibm.com; 
> de...@linuxdriverproject.org; linux-scsi <linux-s...@vger.kernel.org>; LKML 
> <linux-ker...@vger.kernel.org>; sta...@vger.kernel.org; Greg KH 
> <gre...@linuxfoundation.org>
> Subject: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] 
> scsi: storvsc: properly set residual data length on errors
>
> Hi Long Li,
>
> A kernel bug report was opened against Ubuntu [0].  After a kernel
> bisect, it was found that reverting the following commit resolved this bug:
>
> commit 40630f462824ee24bc00d692865c86c3828094e0
> Author: Long Li <lon...@microsoft.com>
> Date:   Wed Dec 14 18:46:03 2016 -0800
>
> scsi: storvsc: properly set residual data length on errors
>
>
> The regression was introduced in mainline as of v4.11-rc1.  It was also
> cc'd to stable and has landed in v3.12.y, v4.4.y, v4.9.y and v4.10.y.
>
>
> This regression seems pretty severe since it's preventing virtual
> machines from booting.  It's affecting a couple of users so far.  I was
> hoping to get your feedback, since you are the patch author.  Do you
> think gathering any additional data will help diagnose this issue, or
> would it be best to submit a revert request?
>
>
> Thanks,
>
> Joe
>
>
> [0] http://pad.lv/1674635
>
>
Thanks for the pointer, Stephen.  I'll have this patch tested and
respond with the results.


Joe

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

2017-03-27 Thread Joseph Salisbury 
Hi Long Li,

A kernel bug report was opened against Ubuntu [0].  After a kernel
bisect, it was found that reverting the following commit resolved this bug:

commit 40630f462824ee24bc00d692865c86c3828094e0
Author: Long Li 
Date:   Wed Dec 14 18:46:03 2016 -0800

scsi: storvsc: properly set residual data length on errors


The regression was introduced in mainline as of v4.11-rc1.  It was also
cc'd to stable and has landed in v3.12.y, v4.4.y, v4.9.y and v4.10.y.


This regression seems pretty severe since it's preventing virtual
machines from booting.  It's affecting a couple of users so far.  I was
hoping to get your feedback, since you are the patch author.  Do you
think gathering any additional data will help diagnose this issue, or
would it be best to submit a revert request?


Thanks,

Joe


[0] http://pad.lv/1674635


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[V2][v3.14.y][PATCH 0/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler

2015-06-17 Thread Joseph Salisbury 
From: Nick Meier nme...@microsoft.com

Hyper-V allows a guest to notify the Hyper-V host that a panic
condition occured.  This notification can include up to five 64
bit values.  These 64 bit values are written into crash MSRs.
Once the data has been written into the crash MSRs, the host is
then notified by writing into a Crash Control MSR.  On the Hyper-V
host, the panic notification data is captured in the Windows Event
log as a 18590 event.

Crash MSRs are defined in appendix H of the Hypervisor Top Level
Functional Specification.  At the time of this patch, v4.0 is the
current functional spec.  The URL for the v4.0 document is:

http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor
 Top Level Functional Specification v4.0.docx

Signed-off-by: Nick Meier nme...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
(backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
---
 drivers/hv/hyperv_vmbus.h | 11 +++
 drivers/hv/vmbus_drv.c| 40 
 2 files changed, 51 insertions(+)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index e055176..3f39c73 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -49,6 +49,17 @@ enum hv_cpuid_function {
HVCPUID_IMPLEMENTATION_LIMITS   = 0x4005,
 };
 
+#define  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE   0x400
+
+#define HV_X64_MSR_CRASH_P0   0x4100
+#define HV_X64_MSR_CRASH_P1   0x4101
+#define HV_X64_MSR_CRASH_P2   0x4102
+#define HV_X64_MSR_CRASH_P3   0x4103
+#define HV_X64_MSR_CRASH_P4   0x4104
+#define HV_X64_MSR_CRASH_CTL  0x4105
+
+#define HV_CRASH_CTL_CRASH_NOTIFY 0x8000
+
 /* Define version of the synthetic interrupt controller. */
 #define HV_SYNIC_VERSION   (1)
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 077bb1b..66168c3 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -36,6 +36,8 @@
 #include asm/hyperv.h
 #include asm/hypervisor.h
 #include asm/mshyperv.h
+#include linux/notifier.h
+#include linux/ptrace.h
 #include hyperv_vmbus.h
 
 static struct acpi_device  *hv_acpi_dev;
@@ -44,6 +46,36 @@ static struct tasklet_struct msg_dpc;
 static struct completion probe_event;
 static int irq;
 
+int hyperv_panic_event(struct notifier_block *nb,
+   unsigned long event, void *ptr)
+{
+   struct pt_regs *regs;
+
+   regs = current_pt_regs();
+
+   wrmsrl(HV_X64_MSR_CRASH_P0, regs-ip);
+   wrmsrl(HV_X64_MSR_CRASH_P1, regs-ax);
+   wrmsrl(HV_X64_MSR_CRASH_P2, regs-bx);
+   wrmsrl(HV_X64_MSR_CRASH_P3, regs-cx);
+   wrmsrl(HV_X64_MSR_CRASH_P4, regs-dx);
+
+   /*
+* Let Hyper-V know there is crash data available
+*/
+   wrmsrl(HV_X64_MSR_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block hyperv_panic_block = {
+   .notifier_call = hyperv_panic_event,
+};
+
+struct resource hyperv_mmio = {
+   .name  = hyperv mmio,
+   .flags = IORESOURCE_MEM,
+};
+EXPORT_SYMBOL_GPL(hyperv_mmio);
+
 static int vmbus_exists(void)
 {
if (hv_acpi_dev == NULL)
@@ -747,6 +779,14 @@ static int vmbus_bus_init(int irq)
if (ret)
goto err_alloc;
 
+   /*
+* Only register if the crash MSRs are available
+*/
+   if (ms_hyperv.features  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+   atomic_notifier_chain_register(panic_notifier_list,
+  hyperv_panic_block);
+   }
+
vmbus_request_offers();
 
return 0;
-- 
2.1.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[V2][v3.14.y][PATCH 0/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler

2015-06-17 Thread Joseph Salisbury 
Hello,

Please consider including upstream commits 
96c1d0581d00f7abe033350edb021a9d947d8d81 and
5ef5b6927f14f29cacd78fa1fb861661a5367f13 in the next v3.14.y release.  They were
included mainline as of v4.1-rc1.  They have been tested and confirmed to 
resolve
http://bugs.launchpad.net/bugs/1463584 .


commit 96c1d0581d00f7abe033350edb021a9d947d8d81
Author: Nick Meier nme...@microsoft.com
Date:   Sat Feb 28 11:39:01 2015 -0800

Drivers: hv: vmbus: Add support for VMBus panic notifier handler

commit 5ef5b6927f14f29cacd78fa1fb861661a5367f13
Author: Nick Meier nme...@microsoft.com
Date:   Wed Mar 18 12:29:24 2015 -0700

Drivers: hv: vmbus: Correcting truncation error for constant 
HV_CRASH_CTL_CRASH_NOTIFY


Commit 96c1d05 does not apply cleanly to v3.14.y, so I performed a backport, 
which is in email 1/1.


Sincerely,

Joseph Salisbury


Nick Meier (1):
  Drivers: hv: vmbus: Add support for VMBus panic notifier handler

 drivers/hv/hyperv_vmbus.h | 11 +++
 drivers/hv/vmbus_drv.c| 40 
 2 files changed, 51 insertions(+)

-- 
2.1.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[V2][3.13.y-ckt][PATCH 1/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler

2015-06-17 Thread Joseph Salisbury 
From: Nick Meier nme...@microsoft.com

BugLink: http://bugs.launchpad.net/bugs/1463584

Hyper-V allows a guest to notify the Hyper-V host that a panic
condition occured.  This notification can include up to five 64
bit values.  These 64 bit values are written into crash MSRs.
Once the data has been written into the crash MSRs, the host is
then notified by writing into a Crash Control MSR.  On the Hyper-V
host, the panic notification data is captured in the Windows Event
log as a 18590 event.

Crash MSRs are defined in appendix H of the Hypervisor Top Level
Functional Specification.  At the time of this patch, v4.0 is the
current functional spec.  The URL for the v4.0 document is:

http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor
 Top Level Functional Specification v4.0.docx

Signed-off-by: Nick Meier nme...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
(backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
---
 drivers/hv/hyperv_vmbus.h | 11 +++
 drivers/hv/vmbus_drv.c| 40 
 2 files changed, 51 insertions(+)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 9fa0cab..7a68d28a 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -49,6 +49,17 @@ enum hv_cpuid_function {
HVCPUID_IMPLEMENTATION_LIMITS   = 0x4005,
 };
 
+#define  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE   0x400
+
+#define HV_X64_MSR_CRASH_P0   0x4100
+#define HV_X64_MSR_CRASH_P1   0x4101
+#define HV_X64_MSR_CRASH_P2   0x4102
+#define HV_X64_MSR_CRASH_P3   0x4103
+#define HV_X64_MSR_CRASH_P4   0x4104
+#define HV_X64_MSR_CRASH_CTL  0x4105
+
+#define HV_CRASH_CTL_CRASH_NOTIFY 0x8000
+
 /* Define version of the synthetic interrupt controller. */
 #define HV_SYNIC_VERSION   (1)
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 48aad4f..4b3d72a 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -37,6 +37,8 @@
 #include asm/hyperv.h
 #include asm/hypervisor.h
 #include asm/mshyperv.h
+#include linux/notifier.h
+#include linux/ptrace.h
 #include hyperv_vmbus.h
 
 
@@ -46,6 +48,36 @@ static struct tasklet_struct msg_dpc;
 static struct completion probe_event;
 static int irq;
 
+int hyperv_panic_event(struct notifier_block *nb,
+   unsigned long event, void *ptr)
+{
+   struct pt_regs *regs;
+
+   regs = current_pt_regs();
+
+   wrmsrl(HV_X64_MSR_CRASH_P0, regs-ip);
+   wrmsrl(HV_X64_MSR_CRASH_P1, regs-ax);
+   wrmsrl(HV_X64_MSR_CRASH_P2, regs-bx);
+   wrmsrl(HV_X64_MSR_CRASH_P3, regs-cx);
+   wrmsrl(HV_X64_MSR_CRASH_P4, regs-dx);
+
+   /*
+* Let Hyper-V know there is crash data available
+*/
+   wrmsrl(HV_X64_MSR_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block hyperv_panic_block = {
+   .notifier_call = hyperv_panic_event,
+};
+
+struct resource hyperv_mmio = {
+   .name  = hyperv mmio,
+   .flags = IORESOURCE_MEM,
+};
+EXPORT_SYMBOL_GPL(hyperv_mmio);
+
 static int vmbus_exists(void)
 {
if (hv_acpi_dev == NULL)
@@ -749,6 +781,14 @@ static int vmbus_bus_init(int irq)
if (ret)
goto err_alloc;
 
+   /*
+* Only register if the crash MSRs are available
+*/
+   if (ms_hyperv.features  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+   atomic_notifier_chain_register(panic_notifier_list,
+  hyperv_panic_block);
+   }
+
vmbus_request_offers();
 
return 0;
-- 
2.1.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[V2][3.13.y-ckt][PATCH 0/1][Hyper-V] Add support for VMBus panic notifier handler

2015-06-17 Thread Joseph Salisbury 
Hello,

Please consider including upstream commits 
96c1d0581d00f7abe033350edb021a9d947d8d81 and
5ef5b6927f14f29cacd78fa1fb861661a5367f13 in the next v3.13.y-ckt release.  They 
were
included mainline as of v4.1-rc1.  They have been tested and confirmed to 
resolve
http://bugs.launchpad.net/bugs/1463584 .


commit 96c1d0581d00f7abe033350edb021a9d947d8d81
Author: Nick Meier nme...@microsoft.com
Date:   Sat Feb 28 11:39:01 2015 -0800

Drivers: hv: vmbus: Add support for VMBus panic notifier handler

commit 5ef5b6927f14f29cacd78fa1fb861661a5367f13
Author: Nick Meier nme...@microsoft.com
Date:   Wed Mar 18 12:29:24 2015 -0700

Drivers: hv: vmbus: Correcting truncation error for constant 
HV_CRASH_CTL_CRASH_NOTIFY


Commit 96c1d05 does not apply cleanly to v3.13.y-ckt, so I performed a 
backport, which is
in email 1/1.


Sincerely,

Joseph Salisbury


Nick Meier (1):
  Drivers: hv: vmbus: Add support for VMBus panic notifier handler

 drivers/hv/hyperv_vmbus.h | 11 +++
 drivers/hv/vmbus_drv.c| 40 
 2 files changed, 51 insertions(+)

-- 
2.1.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[3.13.y-ckt][PATCH 1/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler

2015-06-16 Thread Joseph Salisbury 
From: Nick Meier nme...@microsoft.com

BugLink: http://bugs.launchpad.net/bugs/1463584

Hyper-V allows a guest to notify the Hyper-V host that a panic
condition occured.  This notification can include up to five 64
bit values.  These 64 bit values are written into crash MSRs.
Once the data has been written into the crash MSRs, the host is
then notified by writing into a Crash Control MSR.  On the Hyper-V
host, the panic notification data is captured in the Windows Event
log as a 18590 event.

Crash MSRs are defined in appendix H of the Hypervisor Top Level
Functional Specification.  At the time of this patch, v4.0 is the
current functional spec.  The URL for the v4.0 document is:

http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor
 Top Level Functional Specification v4.0.docx

Signed-off-by: Nick Meier nme...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
(backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
---
 drivers/hv/hyperv_vmbus.h | 11 +++
 drivers/hv/vmbus_drv.c| 35 +++
 2 files changed, 46 insertions(+)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index e1bca88..0a63125 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -49,6 +49,17 @@ enum hv_cpuid_function {
HVCPUID_IMPLEMENTATION_LIMITS   = 0x4005,
 };
 
+#define  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE   0x400
+
+#define HV_X64_MSR_CRASH_P0   0x4100
+#define HV_X64_MSR_CRASH_P1   0x4101
+#define HV_X64_MSR_CRASH_P2   0x4102
+#define HV_X64_MSR_CRASH_P3   0x4103
+#define HV_X64_MSR_CRASH_P4   0x4104
+#define HV_X64_MSR_CRASH_CTL  0x4105
+
+#define HV_CRASH_CTL_CRASH_NOTIFY 0x8000
+
 /* Define version of the synthetic interrupt controller. */
 #define HV_SYNIC_VERSION   (1)
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index ec88c22..0fc7706 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -37,6 +37,8 @@
 #include asm/hyperv.h
 #include asm/hypervisor.h
 #include asm/mshyperv.h
+#include linux/notifier.h
+#include linux/ptrace.h
 #include hyperv_vmbus.h
 
 
@@ -46,6 +48,31 @@ static struct tasklet_struct msg_dpc;
 static struct completion probe_event;
 static int irq;
 
+
+int hyperv_panic_event(struct notifier_block *nb,
+   unsigned long event, void *ptr)
+{
+   struct pt_regs *regs;
+
+   regs = current_pt_regs();
+
+   wrmsrl(HV_X64_MSR_CRASH_P0, regs-ip);
+   wrmsrl(HV_X64_MSR_CRASH_P1, regs-ax);
+   wrmsrl(HV_X64_MSR_CRASH_P2, regs-bx);
+   wrmsrl(HV_X64_MSR_CRASH_P3, regs-cx);
+   wrmsrl(HV_X64_MSR_CRASH_P4, regs-dx);
+
+   /*
+* Let Hyper-V know there is crash data available
+*/
+   wrmsrl(HV_X64_MSR_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block hyperv_panic_block = {
+   .notifier_call = hyperv_panic_event,
+};
+
 struct resource hyperv_mmio = {
.name  = hyperv mmio,
.flags = IORESOURCE_MEM,
@@ -755,6 +782,14 @@ static int vmbus_bus_init(int irq)
if (ret)
goto err_alloc;
 
+   /*
+* Only register if the crash MSRs are available
+*/
+   if (ms_hyperv.features  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+   atomic_notifier_chain_register(panic_notifier_list,
+  hyperv_panic_block);
+   }
+
vmbus_request_offers();
 
return 0;
-- 
2.1.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[3.13.y-ckt][PATCH 0/1][Hyper-V] Add support for VMBus panic notifier handler

2015-06-16 Thread Joseph Salisbury 
Hello,

Please consider including upstream commits 
96c1d0581d00f7abe033350edb021a9d947d8d81 and
5ef5b6927f14f29cacd78fa1fb861661a5367f13 in the next v3.13.y-ckt release.  They 
were
included mainline as of v4.1-rc1.  They have been tested and confirmed to 
resolve
http://bugs.launchpad.net/bugs/1463584 .


commit 96c1d0581d00f7abe033350edb021a9d947d8d81
Author: Nick Meier nme...@microsoft.com
Date:   Sat Feb 28 11:39:01 2015 -0800

Drivers: hv: vmbus: Add support for VMBus panic notifier handler

commit 5ef5b6927f14f29cacd78fa1fb861661a5367f13
Author: Nick Meier nme...@microsoft.com
Date:   Wed Mar 18 12:29:24 2015 -0700

Drivers: hv: vmbus: Correcting truncation error for constant 
HV_CRASH_CTL_CRASH_NOTIFY


Commit 96c1d05 does not apply cleanly to v3.13.y-ckt, so I performed a 
backport, which is
in email 1/1.


Sincerely,

Joseph Salisbury







Nick Meier (2):
  Drivers: hv: vmbus: Add support for VMBus panic notifier handler
  Drivers: hv: vmbus: Correcting truncation error for constant
HV_CRASH_CTL_CRASH_NOTIFY

 drivers/hv/hyperv_vmbus.h | 11 +++
 drivers/hv/vmbus_drv.c| 35 +++
 2 files changed, 46 insertions(+)

-- 
2.1.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [3.13.y-ckt][PATCH 0/1][Hyper-V] Add support for VMBus panic notifier handler

2015-06-16 Thread Joseph Salisbury 
On 06/16/2015 04:41 PM, Greg KH wrote:
 On Tue, Jun 16, 2015 at 04:10:46PM -0400, Joseph Salisbury wrote:
 Hello,

 Please consider including upstream commits 
 96c1d0581d00f7abe033350edb021a9d947d8d81 and
 5ef5b6927f14f29cacd78fa1fb861661a5367f13 in the next v3.13.y-ckt release.  
 They were
 included mainline as of v4.1-rc1.  They have been tested and confirmed to 
 resolve
 http://bugs.launchpad.net/bugs/1463584 .
 Multiple messages sent with the same message-id, yet different subjects
 and content.  That's a sure way to have your messages dropped into a
 spam folder...

 Please fix your way of submitting these and resend properly.

 thanks,

 greg k-h

Thanks for the feedback.  I'll fix things up and resend for all the
stable kernels.

Thanks,

Joe
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[v3.14.y][PATCH 1/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler

2015-06-16 Thread Joseph Salisbury 
From: Nick Meier nme...@microsoft.com


Hyper-V allows a guest to notify the Hyper-V host that a panic
condition occured.  This notification can include up to five 64
bit values.  These 64 bit values are written into crash MSRs.
Once the data has been written into the crash MSRs, the host is
then notified by writing into a Crash Control MSR.  On the Hyper-V
host, the panic notification data is captured in the Windows Event
log as a 18590 event.

Crash MSRs are defined in appendix H of the Hypervisor Top Level
Functional Specification.  At the time of this patch, v4.0 is the
current functional spec.  The URL for the v4.0 document is:

http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor
 Top Level Functional Specification v4.0.docx

Signed-off-by: Nick Meier nme...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
(backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com

Conflicts:
drivers/hv/vmbus_drv.c
---
 drivers/hv/hyperv_vmbus.h | 11 +++
 drivers/hv/vmbus_drv.c| 40 
 2 files changed, 51 insertions(+)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index e055176..3f39c73 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -49,6 +49,17 @@ enum hv_cpuid_function {
HVCPUID_IMPLEMENTATION_LIMITS   = 0x4005,
 };
 
+#define  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE   0x400
+
+#define HV_X64_MSR_CRASH_P0   0x4100
+#define HV_X64_MSR_CRASH_P1   0x4101
+#define HV_X64_MSR_CRASH_P2   0x4102
+#define HV_X64_MSR_CRASH_P3   0x4103
+#define HV_X64_MSR_CRASH_P4   0x4104
+#define HV_X64_MSR_CRASH_CTL  0x4105
+
+#define HV_CRASH_CTL_CRASH_NOTIFY 0x8000
+
 /* Define version of the synthetic interrupt controller. */
 #define HV_SYNIC_VERSION   (1)
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 077bb1b..66168c3 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -36,6 +36,8 @@
 #include asm/hyperv.h
 #include asm/hypervisor.h
 #include asm/mshyperv.h
+#include linux/notifier.h
+#include linux/ptrace.h
 #include hyperv_vmbus.h
 
 static struct acpi_device  *hv_acpi_dev;
@@ -44,6 +46,36 @@ static struct tasklet_struct msg_dpc;
 static struct completion probe_event;
 static int irq;
 
+int hyperv_panic_event(struct notifier_block *nb,
+   unsigned long event, void *ptr)
+{
+   struct pt_regs *regs;
+
+   regs = current_pt_regs();
+
+   wrmsrl(HV_X64_MSR_CRASH_P0, regs-ip);
+   wrmsrl(HV_X64_MSR_CRASH_P1, regs-ax);
+   wrmsrl(HV_X64_MSR_CRASH_P2, regs-bx);
+   wrmsrl(HV_X64_MSR_CRASH_P3, regs-cx);
+   wrmsrl(HV_X64_MSR_CRASH_P4, regs-dx);
+
+   /*
+* Let Hyper-V know there is crash data available
+*/
+   wrmsrl(HV_X64_MSR_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block hyperv_panic_block = {
+   .notifier_call = hyperv_panic_event,
+};
+
+struct resource hyperv_mmio = {
+   .name  = hyperv mmio,
+   .flags = IORESOURCE_MEM,
+};
+EXPORT_SYMBOL_GPL(hyperv_mmio);
+
 static int vmbus_exists(void)
 {
if (hv_acpi_dev == NULL)
@@ -747,6 +779,14 @@ static int vmbus_bus_init(int irq)
if (ret)
goto err_alloc;
 
+   /*
+* Only register if the crash MSRs are available
+*/
+   if (ms_hyperv.features  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+   atomic_notifier_chain_register(panic_notifier_list,
+  hyperv_panic_block);
+   }
+
vmbus_request_offers();
 
return 0;
-- 
2.1.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[v3.16.y-ckt][v3.18.y][v3.19.y-ckt][v4.0.y][PATCH 1/1]Drivers: hv: vmbus: Add support for VMBus panic notifier handler

2015-06-16 Thread Joseph Salisbury 
From: Nick Meier nme...@microsoft.com

BugLink: http://bugs.launchpad.net/bugs/1463584

Hyper-V allows a guest to notify the Hyper-V host that a panic
condition occured.  This notification can include up to five 64
bit values.  These 64 bit values are written into crash MSRs.
Once the data has been written into the crash MSRs, the host is
then notified by writing into a Crash Control MSR.  On the Hyper-V
host, the panic notification data is captured in the Windows Event
log as a 18590 event.

Crash MSRs are defined in appendix H of the Hypervisor Top Level
Functional Specification.  At the time of this patch, v4.0 is the
current functional spec.  The URL for the v4.0 document is:

http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor
 Top Level Functional Specification v4.0.docx

Signed-off-by: Nick Meier nme...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
(Backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
---
 drivers/hv/hyperv_vmbus.h | 11 +++
 drivers/hv/vmbus_drv.c| 35 +++
 2 files changed, 46 insertions(+)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 44b1c94..e54825c 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -49,6 +49,17 @@ enum hv_cpuid_function {
HVCPUID_IMPLEMENTATION_LIMITS   = 0x4005,
 };
 
+#define  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE   0x400
+
+#define HV_X64_MSR_CRASH_P0   0x4100
+#define HV_X64_MSR_CRASH_P1   0x4101
+#define HV_X64_MSR_CRASH_P2   0x4102
+#define HV_X64_MSR_CRASH_P3   0x4103
+#define HV_X64_MSR_CRASH_P4   0x4104
+#define HV_X64_MSR_CRASH_CTL  0x4105
+
+#define HV_CRASH_CTL_CRASH_NOTIFY 0x8000
+
 /* Define version of the synthetic interrupt controller. */
 #define HV_SYNIC_VERSION   (1)
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 35e3f42..c28e225 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -36,6 +36,8 @@
 #include asm/hyperv.h
 #include asm/hypervisor.h
 #include asm/mshyperv.h
+#include linux/notifier.h
+#include linux/ptrace.h
 #include hyperv_vmbus.h
 
 static struct acpi_device  *hv_acpi_dev;
@@ -44,6 +46,31 @@ static struct tasklet_struct msg_dpc;
 static struct completion probe_event;
 static int irq;
 
+
+int hyperv_panic_event(struct notifier_block *nb,
+   unsigned long event, void *ptr)
+{
+   struct pt_regs *regs;
+
+   regs = current_pt_regs();
+
+   wrmsrl(HV_X64_MSR_CRASH_P0, regs-ip);
+   wrmsrl(HV_X64_MSR_CRASH_P1, regs-ax);
+   wrmsrl(HV_X64_MSR_CRASH_P2, regs-bx);
+   wrmsrl(HV_X64_MSR_CRASH_P3, regs-cx);
+   wrmsrl(HV_X64_MSR_CRASH_P4, regs-dx);
+
+   /*
+* Let Hyper-V know there is crash data available
+*/
+   wrmsrl(HV_X64_MSR_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block hyperv_panic_block = {
+   .notifier_call = hyperv_panic_event,
+};
+
 struct resource hyperv_mmio = {
.name  = hyperv mmio,
.flags = IORESOURCE_MEM,
@@ -744,6 +771,14 @@ static int vmbus_bus_init(int irq)
if (ret)
goto err_alloc;
 
+   /*
+* Only register if the crash MSRs are available
+*/
+   if (ms_hyperv.features  HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+   atomic_notifier_chain_register(panic_notifier_list,
+  hyperv_panic_block);
+   }
+
vmbus_request_offers();
 
return 0;
-- 
2.1.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH][v3.18.y][3.19.y-ckt][4.0.y] storvsc: Set the SRB flags correctly when no data transfer is, needed

2015-06-05 Thread Joseph Salisbury 
Hello,

Please consider including mainline commit
dc45708ca9988656d706940df5fd102672c5de92 in the next v3.18.y, v4.0.y and
3.19.y-ckt stable releases.  It was
included in the mainline tree as of v4.1-rc5.  It has been tested and
confirmed to resolve the following bug:
http://bugs.launchpad.net/bugs/1439780
 
commit dc45708ca9988656d706940df5fd102672c5de92
Author: K. Y. Srinivasan k...@microsoft.com
Date:   Fri May 1 11:03:02 2015 -0700

storvsc: Set the SRB flags correctly when no data transfer is needed



Sincerely,

Joseph Salisbury


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH][v3.18.y][3.19.y-ckt][4.0.y] storvsc: Set the SRB flags correctly when no data transfer is, needed

2015-06-05 Thread Joseph Salisbury 
On 06/05/2015 01:51 PM, Joseph Salisbury wrote:
 Hello,
 
 Please consider including mainline commit
 dc45708ca9988656d706940df5fd102672c5de92 in the next v3.18.y, v4.0.y and
 3.19.y-ckt stable releases.  It was
 included in the mainline tree as of v4.1-rc5.  It has been tested and
 confirmed to resolve the following bug:
 http://bugs.launchpad.net/bugs/1439780
  
 commit dc45708ca9988656d706940df5fd102672c5de92
 Author: K. Y. Srinivasan k...@microsoft.com
 Date:   Fri May 1 11:03:02 2015 -0700

 storvsc: Set the SRB flags correctly when no data transfer is needed



 Sincerely,

 Joseph Salisbury


It looks like this commit was already cc'd to stable.  Sorry for the noise.

Thanks,

Joe
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup

2013-09-27 Thread Joseph Salisbury 
On 09/27/2013 06:50 AM, Jiri Kosina wrote:
 On Wed, 25 Sep 2013, Joseph Salisbury wrote:

 After further testing reverting the following commit does in fact
 resolve the bug:

 commit b1a1442a23776756b254b69786848a94d92445ba
 Author: Jiri Kosina jkos...@suse.cz
 Date: Mon Jun 3 11:27:48 2013 +0200

 HID: core: fix reporting of raw events

 Reverting this commit in v3.12-rc2 prevents the system from locking up, 
 which happens when connecting a bluetooth trackpad.

 Jiri, do you think we should revert this patch, or is there some further 
 debugging/data collecting you would like to do?
 Hi Joseph,

 in this mail:

   Message-ID: 5241992e.3090...@canonical.com
   Date: Tue, 24 Sep 2013 09:52:46 -0400

 you said that reverting this commit doesn't prevent the lockups, so I am 
 rather confused ... ?

 Thanks,

The testing was invalid.  Reverting commit b1a1442 does resolve the bug
and stop the lockups.

Thanks,

Joe
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup

2013-09-24 Thread Joseph Salisbury 
On 09/24/2013 05:29 AM, Jiri Kosina wrote:
 On Mon, 16 Sep 2013, Joseph Salisbury wrote:

 Can you explain a little further?  Mark commit a4a23f6 as bad?  An
 initial bisect already reported that was the first bad commit, so it
 can't be marked bad.  The oops on memcpy() happens after commit a4a23f6
 is reverted.  The oops on memcpy() did not happen before a4a23f6 was
 committed, so I assume this new oops was introduced by a change later.

 Right now I'm bisecting down the oops on memcpy() by updating the bisect
 with good or bad, depending if the test kernel hit the oops.  I then
 revert a4a23f6, so that revert is the HEAD of the tree each time before
 building the kernel again(As long as the commit spit out by bisect is
 after when a4a23f6 was introduced).
 Yep.  Please continue bisecting the memcpy() oops.

 kmemdup() is just a kzalloc() followed by a memcpy().  When we split it
 apart by reverting the patch then we would expect the oops to move to
 the memcpy() part.  Somehow desc is a bogus pointer, but I don't
 immediately see how that is possible.

 regards,
 dan carpenter
 Thanks for the details.  We'll continue the bisect and let you know how
 it goes.
 Did this please yield any useful result?

 Thanks,

Thanks for following up, Jiri.  It's been a little tricky narrowing this
one down.  We bisected a couple of times, and both bisects indicated the
following commits as the first bad:

commit b1a1442a23776756b254b69786848a94d92445ba
Author: Jiri Kosina jkos...@suse.cz
Date: Mon Jun 3 11:27:48 2013 +0200

HID: core: fix reporting of raw events

However, reverting this commit does not stop the system from locking up,
when the wireless trackpad is connected.  I was thinking of maybe using
a brute force method and pulling out all the HID changes, added in
3.11-rc1 to ensure the bug goes away.  Then add a group back in at a
time to narrow down the commit that introduced this.  The bisect should
have done this, but I'm not sure why it didn't.  It would be greatly
appreciated if you had any other suggestions on tracking down the cause?

Thanks,

Joe



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup

2013-09-16 Thread Joseph Salisbury 
Hi Thomas,

A bug was opened against the Ubuntu kernel[0].  After a kernel bisect,
it was found that reverting the following commit resolved
this bug:

commit a4a23f6d68ad2c86ee8df6a6f89c9d315c0a761c
Author: Thomas Meyer tho...@m3y3r.de
Date:   Sat Jun 1 11:40:31 2013 +0200

HID: hyperv: convert alloc+memcpy to memdup


The regression was introduced as of v3.11-rc1.  The bug causes a system
to lockup when connecting a bluetooth trackpad and has been reported on
multiple machines. 

I wanted to ping you since you are the author of this patch.  I was
thinking of requesting a revert for v3.12 and v3.11, but I wanted to get
your feedback first.

Reverting the patch changes the driver back to useing kzalloc() and
memcpy() instead of  kmemdup.  Doing so has uncovered another bug, which
causes an oops on memcpy()[1].  We are in the process of bisecting that
one now and will provide the results.


Thanks,

Joe

[0] pad.lv/1218004
[1]
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1218004/+attachment/3818671/+files/kern.log

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup

2013-09-16 Thread Joseph Salisbury 
On 09/16/2013 04:38 PM, Dan Carpenter wrote:
 On Mon, Sep 16, 2013 at 01:42:35PM -0400, Joseph Salisbury wrote:
 Reverting the patch changes the driver back to useing kzalloc() and
 memcpy() instead of  kmemdup.  Doing so has uncovered another bug, which
 causes an oops on memcpy()[1].  We are in the process of bisecting that
 one now and will provide the results.
 The two bugs are the same it's that the code has shifted a little.  Mark
 the commit as buggy and continue with the git bisect.

 regards,
 dan carpenter
Can you explain a little further?  Mark commit a4a23f6 as bad?  An
initial bisect already reported that was the first bad commit, so it
can't be marked bad.  The oops on memcpy() happens after commit a4a23f6
is reverted.  The oops on memcpy() did not happen before a4a23f6 was
committed, so I assume this new oops was introduced by a change later.

Right now I'm bisecting down the oops on memcpy() by updating the bisect
with good or bad, depending if the test kernel hit the oops.  I then
revert a4a23f6, so that revert is the HEAD of the tree each time before
building the kernel again(As long as the commit spit out by bisect is
after when a4a23f6 was introduced).

Thanks,

Joe


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel