Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751790AbbGWFyO (ORCPT ); Thu, 23 Jul 2015 01:54:14 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:33889 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750771AbbGWFyI (ORCPT ); Thu, 23 Jul 2015 01:54:08 -0400 Date: Thu, 23 Jul 2015 08:54:03 +0300 From: Alexander To: Peter Hurley Cc: yalin wang , Arun KS , "linux-kernel@vger.kernel.org" , Arun KS Subject: Re: Why linux console designed to work in polling mode? Message-Id: <20150723085403.bfb381dd5e4791fb3bec7258@gmail.com> In-Reply-To: <55B00CF8.5070901@hurleysoftware.com> References: <4B1FBBE4-9DDC-4D13-B276-80134624CFC8@gmail.com> <20150722230850.9e8111c111b63950ac8f9028@gmail.com> <55B00CF8.5070901@hurleysoftware.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3819 Lines: 83 Hi Peter, I always know the oops enter point(?). Why i can't just switch to old mode (per char busyloop) in this case and do things like in old console unlock? Actually, i suspect that there might be some reliability problems with this deferred stuff, but, actually, i can't come up with a test case (the only one - stuck on all CPUs with disabled interrupts). Thank you for respond. On Wed, 22 Jul 2015 17:36:56 -0400 Peter Hurley wrote: > Hi Alexander, > > On 07/22/2015 04:08 PM, Alexander wrote: > > Hi. Thanks for respond. > > Don't understand how this affects described logic (deferred printk). > > Suppose you put bytes to UART FIFO in console_unlock() until you can, > > after this up_console_sem and move forward. In UART interrupt you will > > do the same thing: get char from log_buf, put into UART FIFO until it > > will be full then break. How the fact that printk could be called from any context > > interfere this? Other way round, this logic will eliminate busyloop > > and decrease printk time significantly (including printk in interrupts etc) > >> it is not easy to implement in a context that you can’t call any sleep function. > > Deferred printing is done in UART interrupt, there is no need to sleep anywhere ... > > Here's an example kernel crash report on the serial console with 'deferred' > serial output on typical 16550A h/w: > > [76330.588297] B > > That's not much to diagnose the crash with. > > Regards, > Peter Hurley > > > On Wed, 22 Jul 2015 14:53:13 +0800 > > yalin wang wrote: > > > >> > >>> On Jul 22, 2015, at 14:27, Arun KS wrote: > >>> > >>> When i checked how kernel printing works, i mentioned that it takes > >>> messages from log_buffer in console_unlock and gives it to > >>> call_console_drivers -> ...-> some uart bsp function. Basically, as i > >>> see this BSP realization tries to flush all message chars in busyloop > >>> ... so it waits until FIFO_NOT_FULL bit will be dropped by UART and it > >>> will be able to push the next byte. Basically, as i see userspace > >>> printing do something different. It puts N_FIFO_BYTES and exits, next, > >>> when FIFO will be freed - interrupt will be generated, and other > >>> characters will be put into UART FIFO. > >>> Can we do something similar for kernel printing? i.e. do not busyloop > >>> sending char after char, but put N_FIFO chars and flush other in > >>> interrupt. When panic will occur we can do busyloop printing again. Is > >>> it reliable? Suppose we have several cores. > >>> > >>> > >> > >> i think it is because printk is very different from other printf function in user space, > >> printk() can be called in any context atomic / non- atomic / irq / soft-irq context .. > >> > >> so your bsp->print function can’t be sleep, can’t call any sleep functions . > >> > >> another reason is that in console_unlock() function, it call bas->print like this: > >> call_console_drivers(level, ext_text, ext_len, text, len); > >> print expect your bsp function print all the text as showed in parameters. > >> and it doesn’t check the return value , > >> so if your driver doesn’t use POLL mode, you should only print N_FIFO_BYTES bytes, > >> this need prink to check return value or need your bsp function to use some special method > >> to send the remaining bytes after received FIFO empty interrupt. > >> it is not easy to implement in a context that you can’t call any sleep function. > >> > >> Thanks > > > -- Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/