Timothy, You have found the problem we are in the process of fixing. We got sidetracked for a while by another problem in another part of the kernel that caused a problem in our drivers. With rc8 that problem magically went away. But it prevented us from seeing the problem you are describing till after RC8. The problem you are seeing and are describing was introduced in one of the patches that has been submitted to the drivers. It hangs on VmbusConnect() / osd_WaitEventWait(msgInfo->WaitEvent) like you saw. It's the waiting point for the interrupts from lower level, which ultimately coming from HyperV host. Last week we took our original submission of the code to Greg, and made minor modifications to allow it to be loaded into 2.6.32. Those Original drivers load fine and seem to work. We thought we had started losing our minds till that point :) So we know that the original drivers work fine, we are now going through the patches and see which ones might have caused The issue you are seeing now. Hopefully we can trace down quickly to see which patch might have introduced the behavior we are seeing. We are committed to providing a fix as soon as possible. Thanks, Hank. -----Original Message----- From: Timothy Bisson [mailto:bissont@xxxxxxxxx] Sent: Monday, September 28, 2009 10:56 PM To: devel@xxxxxxxxxxxxxxxxxxxx Cc: Hank Janssen; Haiyang Zhang Subject: staging: hv: Anyone having success? Hello, Has anyone had success insmoding the hv_vmbus driver? The drivers build for me, but insmoding hv_vmbus.ko hangs. I can however get the v2 version of the linux_integration_components from Microsoft (where vmbus is a binary) to work. It looks like the linux-next driver may not be receiving an interrupt from Hyper-v as vmbus_isr() isn't being called; the 'insmod hv_vmbus.ko hangs until I press ctrl-c, at which point I enter the else statement below (Connection.c) /* Wait for the connection response */ osd_WaitEventWait(msgInfo->WaitEvent); list_del(&msgInfo->MsgListEntry); /* Check if successful */ if (msgInfo->Response.VersionResponse.VersionSupported) { DPRINT_INFO(VMBUS, "Vmbus connected!!"); gVmbusConnection.ConnectState = Connected; } else { DPRINT_ERR(VMBUS, "Vmbus connection failed!!..." "current version (%d) not supported", VMBUS_REVISION_NUMBER); ret = -1; goto Cleanup; } To provide more debug info I increased the loglevel in both versions. Here is the dmesg after building the source from linux-next and trying to insmod hv_vmbus.ko: [ 3128.596317] [VMBUS_DRV]: vmbus_init() enter [ 3128.596322] VMBUS_DRV: Vmbus initializing.... current log level 0x1f1f0009 (1f1f,9) [ 3128.596324] [VMBUS_DRV]: vmbus_bus_init() enter [ 3128.596326] [VMBUS]: VmbusInitialize() enter [ 3128.596327] VMBUS: +++++++ Build Date=Sep 28 2009 21:51:28 +++++++ SNIPPAGE [ 660.473821] VMBUS: VmbusOnISR() received msg type 1 size 16 [ 660.473823] [VMBUS_DRV]: vmbus_isr() exit [ 660.473827] [VMBUS_DRV]: vmbus_msg_dpc() enter [ 660.473831] [VMBUS_DRV]: vmbus_msg_dpc() exit [ 660.473836] VMBUS: VmbusOnChannelMessage() message type 15 size 16 [ 660.473841] VMBUS: Vmbus connected!! .... As I mentioned, it seems there may be a problem with interrupts as we aren't entering vmbus_isr() after the driver issues the hypercall. I tried to debug the code by comparing the dmesg outputs, but once I started looking at HvSynicInit() in Hv.c, I quickly became overwhelmed.... Thanks, Tim _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
