> -----Original Message----- > From: Sitsofe Wheeler > On Tue, Aug 26, 2014 at 10:30:54AM +0000, Dexuan Cui wrote: > > > Actually I found the direct cause of the panic: sometimes > > vmbus_post_msg() can return 4 (HV_STATUS_INVALID_ALIGNMENT), but > > vmbus_open() doesn't propagate this error to the caller > > synthvid_connect_vsp(), and vmbus_open() " goto error1" and frees the > > ringbuffer! So later the access to ring_buffer->read_index is caught > > by CONFIG_DEBUG_PAGEALLOC. > > > > I don't see any "invalid alignment" here... and I can't explain why > > vcpus=4 seems OK... Debugging WIP. I think I found out why we got HV_STATUS_INVALID_ALIGNMENT: according to Hypervisor Top Level Functional Specification(available at http://blogs.msdn.com/b/virtual_pc_guy/archive/2014/02/17/updated-hypervisor-top-level-functional-specification.aspx), do_hypercall() fails due to HV_STATUS_INVALID_ALIGNMENT, if "the specified input or output GPA pointer is not aligned to 8 bytes", or, "the specified input or output parameter lists spans pages". Here the 'input' can rarely across the page boundary, especially when CONFIG_DEBUG_PAGEALLOC is on. I'm making a patch for this. > > > > BTW, please try the attached patch. With it, the VM doesn't panic in > > my side with vcpus=1 and can boot to shell prompt(looks the boot-up is > > very slow. I have to wait for several minutes...) > > A quick tip: inline patches tend to be better than attachments on LKML. > This is because if the mimetype of the attachment is something like > octet/stream then various tools (e.g. > https://lkml.org/lkml/2014/8/26/271 and > https://patchwork.kernel.org/project/LKML/list/?submitter=100981 ) won't > archive/extract the patch... OK, thanks for the reminder! I'll use inline patches(I hope my mail client has been configured to be smart enough to not "auto-format" my inline patches...). > I rebased your patch on top of the K.Y.'s "Drivers: hv: vmbus: Eliminate > calls to BUG_ON()" patch set (see below). The combination no longer > triggers the bug and it doesn't take too long to boot but the network > interface fails to work (which I believe is . the sentence is accidently trimmed here? :-) > > Rebased vmbus open fixes patch. The patch doesn't resolve all the issues. > Boot dmesg output (there's no line that mentions retries). The > framebuffer window also didn't resize itself: > > [ 7.848030] hv_vmbus: registering driver hyperv_fb > [ 7.859759] hyperv_fb: Unable to open vmbus channel > [ 7.871812] hyperv_fb: Unable to connect to VSP We still see hyperv_fb can't work. Thanks, -- Dexuan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
