On Sat 2017-07-08 22:30:47, Tetsuo Handa wrote: > What I want to mention here is that messages which were sent to printk() > were not printed to not only /dev/tty0 but also /dev/ttyS0 (I'm passing > "console=ttyS0,115200n8 console=tty0" to kernel command line.) I don't care > if output to /dev/tty0 is delayed, but I expect that output to /dev/ttyS0 > is not delayed, for I'm anayzing things using printk() output sent to serial > console (serial.log in my VMware configuration). Hitting this problem when we > cannot allocate memory results in failing to save printk() output. Oops, it > is sad. Would it be acceptable to remove "console=tty0" parameter and push the messages only to the serial console? Also there is the patchset from Peter Zijlstra that allows to use early console all the time, see https://lkml.kernel.org/r/20161018170830.405990950@xxxxxxxxxxxxx The current code flushes each line to all enabled consoles one by one. If there is a deadlock in one console, everything gets blocked. We are trying to make printk() more robust. But it is much more complicated than we anticipated. Many changes open another can of worms. It seems to be a job for years. > Hmm... should we consider addressing console_sem problem before > introducing printing kernel thread and offloading to that kernel thread? As Sergey said, the console rework seems to be much bigger task than introducing the kthread. Also if we would want to handle each console separately (as a fallback) it would be helpful to have separate kthread for each enabled console or for the less reliable consoles at least. Best Regards, Petr _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
