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
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
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
> pushpatch 10
> make vmlinux ARCH=um
> 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
> > 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