RE: [PANIC, hyperv] BUG: unable to handle kernel paging request at ffff880077800004 (hv_ringbuffer_write)

[KY Srinivasan <kys@microsoft.com>]

> -----Original Message-----
> From: Dexuan Cui
> Sent: Wednesday, August 27, 2014 8:22 PM
> To: KY Srinivasan; Sitsofe Wheeler
> Cc: Greg Kroah-Hartman; Haiyang Zhang; devel@linuxdriverproject.org;
> linux-kernel@vger.kernel.org
> Subject: RE: [PANIC, hyperv] BUG: unable to handle kernel paging request at
> ffff880077800004 (hv_ringbuffer_write)
> 
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > owner@vger.kernel.org] On Behalf Of KY Srinivasan
> > Sent: Thursday, August 28, 2014 7:14 AM
> > > > > From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> > > > > Sent: Wednesday, August 27, 2014 9:19 AM
> > > > >
> > > > > > BTW, with the patch below, hyperv_fb can work now, BUT,
> > > > > > *occasionally*,
> > > > > > storvsc_probe() -> ... -> vmbus_open() -> can fail due to
> > > > > > HV_STATUS_INVALID_ALIGNMENT...
> > > > >
> > > > > I applied your new patch on top of KY's pieces (it applied
> > > > > cleanly) and while it doesn't blow up, one warning is printed
> > > > > out and the UP boot seemed to stall after input: TPPS/2 message
> > > > > (but pressing ctrl-alt-delete allows the system to reboot cleanly).
> > > >
> > > > First let me thank you guys for looking into this issue. Looking
> > > > at your dmesg, it looked like storvsc probe failed as Dexuan had seen.
> > > > Since the failure appears to be alignment related, perhaps we
> > > > could test with allocating a page all the time (and getting rid of
> > > > the kmalloc). Sitsofe, here is a patch based on Dexuan's patch. If
> > > > this works, I will probably minimize failure cases by
> > > > pre-allocating per-cpu pages for this.:
> > >
> > > After some modifications to apply on top of your previous patches
> > applying
> > > this latest patch has cured the issues surrounding hyperv_fb issues
> > > on
> > boot.
> 
> This always-use-page-allocation patch of KY works for me too. :-)
> 
> 
> > > The only issue seen on boot now is similar to
> > > https://lkml.org/lkml/2014/8/19/227 ...
> Hi Sitsofe,
> I don't see this issue.
> Do you still see the issue for EVERY boot after you applied KY's always-use-
> page-allocation patch?
> I doubt that because in the log of the above link:
> 
> [   34.628072] hv_netvsc vmbus_0_15: net device safe to remove
> [   34.676573] hv_netvsc: hv_netvsc channel opened successfully
> [   34.860292] hv_netvsc vmbus_0_15 eth1: unable to establish send buffer's
> gpadl
> [   34.948983] hv_netvsc vmbus_0_15 eth1: unable to connect to NetVSP - 4
> 
> Here the 4 is just HV_STATUS_INVALID_ALIGNMENT -- it should be fixed by
> the patch.
> 
> >
> > That is good to hear. I was under the impression that this issue would
> > be resolved with all the cleanup we have done. The last patch-set I
> > posted earlier today has the fix for vmbus_open  bug that Dexuan had
> identified.
> >
> > If you could try with the BUG_ON elimination patch-set I sent out
> > earlier today with the fix in hv.c that I had sent that would be great.
> > >
> > > How come previous alignment efforts weren't working out?
> I'm not sure.
> If we trust the hypervisor, I would guess in hv_post_message()
> 1) We'd better add "aligned_msg->reserved = 0;"
> 2) Should we make sure  "aligned_msg->payload_size % 8 == 0"? IMO
>    aligned_msg->payload is an array of 8-byte.
> 
> > I have chosen to always allocate a page and so alignment won't be an
> > issue. I want to eliminate failure in this path and so, I will most
> > likely do a per-cpu pre-allocation of this buffer.
> This is a good idea!

Thank you all. I will submit a patch with the pre-allocated per-cpu page for this.

K. Y
> 
> Thanks,
> -- Dexuan