lkml.org 
[lkml]   [2014]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PANIC, hyperv] BUG: unable to handle kernel paging request at ffff880077800004 (hv_ringbuffer_write)
Date
> -----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


\
 
 \ /
  Last update: 2014-08-27 13:41    [W:0.109 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site