> -----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@xxxxxxxxxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx > Subject: RE: [PANIC, hyperv] BUG: unable to handle kernel paging request at > ffff880077800004 (hv_ringbuffer_write) > > > -----Original Message----- > > From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel- > > owner@xxxxxxxxxxxxxxx] On Behalf Of KY Srinivasan > > Sent: Thursday, August 28, 2014 7:14 AM > > > > > From: Sitsofe Wheeler [mailto:sitsofe@xxxxxxxxx] > > > > > 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
