On giovedì 13 settembre 2007, Fermín Galán Márquez wrote:
> Hi,
>
> After some more debugging I think I've solved the problem (at least :)
> An explanation follows.
>
> First, although apparently it seemed that the modules causing the
> problem were the ones related with networking (as David Fernández said
> in his mail) that assumption was wrong. In fact, the modules causing the
> problem are the ones that print some message in the "kernel message
> buffer" (I don't know what is the right name, but I'm referring to the
> message log that appears when the dmesg command is used) when modprobe
> load them. For example, ip_tables prints something like "ip_tables: (C)
> 2000-2006 Netfilter Core Team".

> The solution to the problem is using con1 instead of con0, I mean:
>
> ./linux ubd0=/tmp/root_fs_debug con=null con1=pts uml_dir=/tmp umid=run
>
> instead of
>
> ./linux ubd0=/tmp/root_fs_debug con=null con1=pts uml_dir=/tmp umid=run

This was con0=pts, I checked your other mail. Right?

> In that case you can 'iptables -L' works without problems.

> Why? When the module is loaded it prints its message not only in the
> internal kernel message buffer but also in con0 (this can be checked
> running simply "./linux ubd0=/tmp/root_fs_debug", without con=
> redirectors). When con0 is redirected to null (con0=null) there is no
> problem, but if con0 is redirected to a pts (con0=pts) I guess that, in
> the moment of printing the message, some problem occurs with the output
> (as Jeff suggest in its mail) thus causing the vm hang.

> This explains also why putting the module in /etc/modules works. The
> loading of the list of modules in /etc/modules is performed before UML
> assign virtual console to pts devices (the sequence can be checked
> observing the booting log).

> I think that my solution is more a workaround that a definitive
> solution. Why when con0 is assigned to a pts modules can not (because of
> it hangs the vm) print its message but when it is assigned to null it
> works? Is there a bug in the UML kernel that need to be fixed? Or maybe
> the bug is in modprobe? I leave the question open for the experts in the
> UML internals... :)
The problem does not lie in modprobe nor iptables - it is the behaviour of the 
system console wrt. the pts driver.

The only really strange thing is the 100% cpu usage - like if the operation 
were retried in a loop. And, well, there is a loop there - CATCH_EINTR (which 
I added)!

Now, what's unexpected is getting EINTR on that operation. That's really 
strange. However, I'll leave debugging to Jeff. If he cannot reproduce the 
problem he'll ask you more, I guess.

> Regarding the tests suggested by Paolo:
> > Please try logging in via SSH and reproducing the problem and the
> > stacktrace, and also removing con=null - also have you double checked
> > con=null is ok (maybe it was con=none, I'm not sure). I'm not sure screen
> > is perfectly safe to use (it should be).
>
> Do you really need that I perform these test or considers the report
> above is enough? If it's really needed I can do them, but it would take
> me some time (and maybe now it isn't a good idea because of they won't
> provide additional useful information :)

No, I just needed a proof that the problem was indeed with the output on a 
pts.

Thank you for you help
-- 
"Doh!" (cit.), I've made another mistake!
Paolo Giarrusso, aka Blaisorblade