Re: Why linux console designed to work in polling mode?

[Alexander <alexhoppus111@gmail.com>]

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 <peter@hurleysoftware.com> 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 <yalin.wang2010@gmail.com> wrote:
> > 
> >>
> >>> On Jul 22, 2015, at 14:27, Arun KS <arunks.linux@gmail.com> 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 <alexhoppus111@gmail.com>