[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EE124450C0AAF944A40DD71E61F878C996493E@SINEX14MBXC419.southpacific.corp.microsoft.com>
Date: Wed, 27 Aug 2014 11:30:54 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: Sitsofe Wheeler <sitsofe@...il.com>
CC: KY Srinivasan <kys@...rosoft.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PANIC, hyperv] BUG: unable to handle kernel paging request at
ffff880077800004 (hv_ringbuffer_write)
> -----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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists