Whatever it is about c3bc26d that makes the VMs on my work computer ill doesn't bother the VMs on my home computer, so I can boot linux-next and mainline here at home. At work my host computer is running Centos-7, I hope the problem there isn't old QEMU stuff - I guess plenty of y'all use QEMU VMs hosted on Centos-7? But the fix to the b96809 problem has changed the arguments to xattr handlers in mainline, so Andreas' Orangefs patches no longer apply. Andreas', when this settles down, would you be willing to redo and resend your patches? -Mike On Fri, May 27, 2016 at 5:24 PM, Mike Marshall <hubcap@xxxxxxxxxxxx> wrote: > 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
