[v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup
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 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
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
Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup
On 09/16/2013 05:05 PM, Dan Carpenter wrote: > On Mon, Sep 16, 2013 at 04:49:29PM -0400, Joseph Salisbury wrote: >> 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). > 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. Thanks again, 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
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 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
Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup
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, > We also tested the 3.12-rc2 kernel, but it also produces an oops and lockup. In case it's of use, the 3.12-rc2 oops can be seen at: https://launchpadlibrarian.net/151359441/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
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, > After further testing reverting the following commit does in fact resolve the bug: commit b1a1442a23776756b254b69786848a94d92445ba Author: Jiri Kosina 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? 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
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 >> 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
[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 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
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
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 > 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 > Reviewed-by: K. Y. Srinivasan > Reviewed-by: Christoph Hellwig > Signed-off-by: Martin K. Petersen > > -Original Message- > From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] > Sent: Monday, March 27, 2017 1:22 PM > To: Long Li > Cc: KY Srinivasan ; Martin K. Petersen > ; Haiyang Zhang ; Stephen > Hemminger ; j...@linux.vnet.ibm.com; > de...@linuxdriverproject.org; linux-scsi ; LKML > ; sta...@vger.kernel.org; Greg KH > > 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 > 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
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
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 > 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 > Reviewed-by: K. Y. Srinivasan > Reviewed-by: Christoph Hellwig > Signed-off-by: Martin K. Petersen > > -Original Message- > From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] > Sent: Monday, March 27, 2017 1:22 PM > To: Long Li > Cc: KY Srinivasan ; Martin K. Petersen > ; Haiyang Zhang ; Stephen > Hemminger ; j...@linux.vnet.ibm.com; > de...@linuxdriverproject.org; linux-scsi ; LKML > ; sta...@vger.kernel.org; Greg KH > > 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 > 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: [PATCH][v3.18.y][3.19.y-ckt][4.0.y] storvsc: Set the SRB flags correctly when no data transfer is, needed
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 > 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
[PATCH][v3.18.y][3.19.y-ckt][4.0.y] storvsc: Set the SRB flags correctly when no data transfer is, needed
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 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
[3.13.y-ckt][PATCH 1/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler
From: Nick Meier
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
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
(backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury
---
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
#include
#include
+#include
+#include
#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
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 Date: Sat Feb 28 11:39:01 2015 -0800 Drivers: hv: vmbus: Add support for VMBus panic notifier handler commit 5ef5b6927f14f29cacd78fa1fb861661a5367f13 Author: Nick Meier 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
[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
From: Nick Meier
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
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
(Backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury
---
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
#include
#include
+#include
+#include
#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
[v3.14.y][PATCH 1/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler
From: Nick Meier
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
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
(backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury
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
#include
#include
+#include
+#include
#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
Re: [3.13.y-ckt][PATCH 0/1][Hyper-V] Add support for VMBus panic notifier handler
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
[V2][3.13.y-ckt][PATCH 1/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler
From: Nick Meier
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
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
(backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury
---
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
#include
#include
+#include
+#include
#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
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 Date: Sat Feb 28 11:39:01 2015 -0800 Drivers: hv: vmbus: Add support for VMBus panic notifier handler commit 5ef5b6927f14f29cacd78fa1fb861661a5367f13 Author: Nick Meier 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
[V2][v3.14.y][PATCH 0/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler
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 Date: Sat Feb 28 11:39:01 2015 -0800 Drivers: hv: vmbus: Add support for VMBus panic notifier handler commit 5ef5b6927f14f29cacd78fa1fb861661a5367f13 Author: Nick Meier 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][v3.14.y][PATCH 0/1] Drivers: hv: vmbus: Add support for VMBus panic notifier handler
From: Nick Meier
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
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
(backported from commit 96c1d0581d00f7abe033350edb021a9d947d8d81)
Signed-off-by: Joseph Salisbury
---
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
#include
#include
+#include
+#include
#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
[PATCH][v3.8.y] Drivers: hv: Execute shutdown in a thread context
Hello, Please consider including upstream commit: 3dd6cb497198a0533a2530b6a345c60c9a29b9bc in the next v3.8.y release. It was included upstream as of v3.9-rc1. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1180419 . commit 3dd6cb497198a0533a2530b6a345c60c9a29b9bc Author: K. Y. Srinivasan Date: Wed Jan 23 17:42:45 2013 -0800 Drivers: hv: Execute shutdown in a thread context Sincerely, Joseph Salisbury ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
