On Tuesday 07 December 2004 11:13, Paul Warren wrote: > On Tue, Dec 07, 2004 at 03:50:40AM +0100, Blaisorblade wrote: > > > host-skas3-2.4.25-v3.patch > > > > > > The offending patch: > > > > > > 82:a:uml-refuse-to-run-without-skas-if-no-tt-mode-in-fix > > > > Ok, you're fairly handy with patch-scripts! But from the numbers you are > > using -bb2 (which is still fairly buggy). > > Yes - although applying the whole of bb2, bb3 or bb4 gives the same > result, so I went for bb2 to minimise the number of patches I had to > work my way through.
Ok, this makes sense... so maybe you can still test this in -bb2. I was a bit confused because you didn't explain this (at first I wondered about the patch numbers, later I got the idea of looking into -bb2). Only you need to be careful and make sure to do "make clean ARCH=um", since this bites you so hard. If it causes you massive slowdowns, then you could probably like ccache (not sure it helps a lot on the -bb patches, since they are too intrusive - it helps if you rebuild a similar tree as one you built. Headers have to match for ccache to provide benefits). > > > Although it stops running after: > > > > > > 45:a:uml-remove-devfs-mk-symlink > > > > I also don't think that those patches are the exact ones causing the > > problem - you're probably speaking of something in the middle, right? > Well, that was the last patch I applied before the problems (I pushed > the patches 10 at a time, then popped and pushed until I found the exact > one that caused the problem). > The only thing I can think of is that I > didn't do a "make clean" in between each build, so possibly the > offending chnage was a few patches earlier and there's a dependency > problem? Yes, there are dependency problems. In fact, you had worked the right way, but this dependency problem has stepped to us. If you change a .c file that's recompiled, but if you change a header that's not always handled... They are specific to UML, since Kbuild is not enough powerful to handle all of UML; what Kbuild cannot handle is currently handled without the extended dependency handling by UML itself... However, I never hit this problem so hard as you're doing here (since some time I got used to always doing make clean ARCH=um). > > > with a slightly different message: > > > ./vmlinux > > > Checking for /proc/mm...found > > > Checking for the skas3 patch in the host...found > > > Support for TT mode is disabled, and no SKAS support is present on the > > > host. In fact, this bug is a trivial and well-known typo, and caused not by #45, but #43: uml-refuse-to-run-without-skas-if-no-tt-mode-in.patch as I said, the fix is in the uml-refuse-...-fix patch; you should be able to move the patch above in the series file. Only thing you need to know is how to cope with patch-scripts quirks: - never forget the .patch extension - never leave blank lines for what I know, I cannot understand how it's possible to get exactly this result, but for the moment I'll avoid digging on the exact dependency situation needed to cause this... > > Well, that message is a silly bug in 2.6.9-bb1, fixed in -bb2 by #82, > > which is fixed by #82. However, either you skip the first one > > (uml-refuse-to-run-without-skas-if-no-tt-mode-in) or you move the > > second one (the above one with -fix at the end added, #82) to just > > after the first one, you'd get this second bug fixed. > > I still recommend concentrating on -bb4, if possible. Ok, you can ignore this, since there's a good reason. > > At least I think so (I'm enough confident of that), your message seems a > > bit confused - are you applying patches from #1 onwards, right? Or > > reversing them? > Ok. I can go and try the bb4 patch step-by-step, but I know that the > result of applying the whole of bb4 is the same problem as above. > Just to be clear, what I did was I took a vanilla 2.6.9 kernel. I then > did; > pushpatch 10 > make vmlinux ARCH=um > ./vmlinux > When I hit the problem, I did "poppatch 5" and hunted around until I > found the exact patch causing trouble. I then did "pstatus" and > reported the last patch with an "a" next to it. > > I'm not able to make any sense (yet) > > > I've attached a strace, as it is after applying #82. > > Forgot it? However, leave that alone - I'm more interested in making > > sense of the "push-pop patches" test. I'd also like, if you can, to see > > it done on -bb4. > > About -bb4: it should be safe if you apply patches from the top until > > uml-hostfs-add-sendfile.patch, then there is the second block until > > uml-fix-compile-bodo.patch, then some new fixes after that. Well, the blocks are similar in -bb2, only the patches at the "blocks" edge are different. > > At first, I'd suggesting using these three blocks of patches, seeing in > > which one is the problem, and checking further by splitting the block and > > applying only part of it until you get to the guilty one or you can post > > me some more data (as "it works when I apply from #1 to #a, when I apply > > from #a to #b it blocks, so it's in the middle). > OK - I'll try that this evening (UK time). I'm in Italy, so the Timezone matches more or less... but I won't be able to handle that before Thursday. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ User-mode-linux-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
