OK, so now that there's a problem with b96809 that y'all are scrambling to fix, it doesn't seem like my little O_DIRECT patch and Andreas' Orangefs patch series are of the highest priority. But... I set up another VM for linux-next testing, and linux-next won't boot on my VM either. So I git bisected the problem down to c3bc26d, and I'm running, booted, with 9222aa8. I started bisecting on the mainline while I was setting up my linux-next VM, and got done with that bisect first, so it is mainline, not linux-next, that I have bisected here. So... c3bc26d is: ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support in acpi_hw_read() and I have CC'd the Author, Lv, with this message. I guess I have some combination in my .config or something that makes this problem show up for me, surely I'm not the only one on the Internet trying to boot linux-next and mainline <g>... Here is a link to my config file and notes (including git bisect log) I took while doing this bisect. http://myweb.clemson.edu/~hubcap/bisect.c3bc26d/ -Mike On Thu, May 26, 2016 at 7:53 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > 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 <g>... > > 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). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
