From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:46616 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755162AbcEZXxH (ORCPT ); Thu, 26 May 2016 19:53:07 -0400 Date: Fri, 27 May 2016 00:53:03 +0100 From: Al Viro To: Mike Marshall Cc: Andreas Gruenbacher , linux-fsdevel Subject: Re: [PATCH 1/3] orangefs: Remove useless defines Message-ID: <20160526235303.GN14480@ZenIV.linux.org.uk> References: <1464172174-29237-1-git-send-email-agruenba@redhat.com> <1464172174-29237-2-git-send-email-agruenba@redhat.com> <20160526200526.GL14480@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, May 26, 2016 at 06:24:22PM -0400, Mike Marshall wrote: > OK... I see now... ce23e64 (Al's patch) got merged to mainline after > 2dcd0af (Linux 4.6) and Andreas' Orangefs patches won't load > without ce23e64. I was working from vanilla Linux 4.6. My little > O_DIRECT patch is also affected, since .direct_IO lost the offset > argument. > > So... now the top of my local tree is ea8ea73, Andreas' patch > series loads fine, I've fixed my O_DIRECT patch, it loads, and > the whole thing compiles and installs great. But won't boot. On my VM. > Even when built without Andreas' patch series and my O_DIRECT patch > it won't boot. So now I've got it booted with the vanilla 4.6 kernel. > > I guess this is a "tree of the moment" problem. I guess Linus' tree > will continue to evolve and I'll come in tomorrow > and fetch from it again and it will boot. And then I can load > and test the patches, update the Orangefs linux-next and > build the pull request before the merge window ends. > > Maybe after six or eight more merge windows I'll get the > hang of being upstream and quit causing trouble ... Useful tip: run the tests you care about on linux-next. On a regular basis. And have your tree in the mix, while we are at it... Does linux-next circa the beginning of the merge window work for you? If it doesn't, that's the starting point for git bisect you should've run back then (or, better yet, at the time when the breakage in linux-next only started - shorter bisect that way).