Alle 19:00, luned=EC 28 giugno 2004, Don Porter ha scritto:
> Thanks for the tips.
>
> On Fri, 2004-06-25 at 13:07, BlaisorBlade wrote:
> 1)
>
> > Well, strange, except while actually loading the module (you may have
> > tried to see it while the kernel was modifying module_list, maybe). But
> > it's just an idea (and I don't believe a lot in it).
>
> No, I loaded the module, used it a bit, then attached to the tracing
> process with gdb. Am I attaching to the wrong process?
Hm, maybe, but see http://user-mode-linux.sourceforge.net/debugging.html; I=
=20
never debug in TT mode.
> > > 2) For some reason, uml leaves a thread running after a 'halt' that
> > > holds a lock on the filesystem file. If I restart uml without first
> > > issuing a 'killall -9 linux' first, uml will VFS panic because the old
> > > process is holding a lock on the file. Perhaps, though, I am doing
> > > something wrong here? Am I not "rebooting" uml correctly?
> >
> > There is here a workaround for this (which is believed to be a host bug=
);
> > it seems that no thread stays alive, but still the lock is left:
> > http://marasystems.com/download/uml/
>
> The patch fixed reboots, but it didn't fix halts and new starts. A 'ps'
> shows that there is a uml kernel thread hanging around. In fact, each
> time the uml kernel is rebooted, a new kernel thread is left hanging
> around.
>
> File locks have to be tied to a process, correct? Otherwise, how do
> they ever get cleaned up? In any case, I don't think it is a host
> issue, because I have seen it happen on two different distros and three
> different kernels, both in the 2.4 and 2.6 series.
Well, the problem fixed by that patch was for cases when UML exited complet=
ely=20
and the host didn't drop the lock. Yes, a lock without owner.
If one kernel thread remains alive, it means that probably you have SuSE 9.=
1 /=20
Mandrake 10.0 / any distro which gcc enables -funit-at-a-time, which is an=
=20
optimization option unsafe for UML.
> > > 3) Just for kicks, I tried to upgrade to patch3.
> >
> > cp .config UMLConfig
> > make mrproper ARCH=3Dum (this cleans up everything, including .config, =
so I
> > save it)
> > cp UMLConfig .config
>
> It seems that a lot of the building issues are because I did a 'make
> ARCH=3Dum mrproper'. This deletes a lot of symlinks that nothing else
> recreates. I have to manually symlink include/asm, include/asm/arch,
> and make arch/um/include/uml-config.h. It seems like these should make
> automatically.
>
> It seems that the Make rules need some attention in general. A 'make
> ARCH=3Dum -j 2' fails, when a 'make ARCH=3Dum' does not, indicating that =
the
> rules are not multi-process safe. Also,
Yes, it's known, but I've no idea of how to fix this (and quite frankly, it=
's=20
very low priority). Do you think we just have some missing dependencies?
> I can successfully build a patch3 kernel if I untar the source and build
> straight away. If I make mrproper first, it fails.
Hmm, I am used to build UML/2.6, so I could have missed this.
> Also, the patch3 kernel hangs when trying to start cron and the virtual
> consoles.
No idea, sorry (I don't remember if patch1 does this). Try searching for Su=
SE=20
9.1 and unit-at-a-time on the archives, if you have that distro.
=2D-=20
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
|