On 18/12/15 17:00, Daniel Thompson wrote:
The MCE handlers should only call printk() when they decide to panic
and *after* busting the spinlocks. At this point deferring printk()
until it is safe is not very helpful.
When we bust the spinlocks we should probably restore the normal
printk() funct
On Fri, 18 Dec 2015 13:11:41 +0100 Peter Zijlstra wrote:
> On Fri, Dec 18, 2015 at 12:29:02PM +0100, Peter Zijlstra wrote:
> > On Fri, Dec 18, 2015 at 10:18:08AM +, Daniel Thompson wrote:
> > > I'm not entirely sure that this is an improvement.
> >
> > What I do these days is delete everythi
On 18/12/15 14:52, Petr Mladek wrote:
On Fri 2015-12-18 10:18:08, Daniel Thompson wrote:
On 11/12/15 23:26, Jiri Kosina wrote:
On Fri, 11 Dec 2015, Russell King - ARM Linux wrote:
I'm personally happy with the existing code, and I've been wondering why
there's this effort to apply further cle
On Thu 2015-12-17 14:38:58, Andrew Morton wrote:
> On Tue, 15 Dec 2015 15:26:21 +0100 Petr Mladek wrote:
>
> > > OK, thanks. So "not needed at present, might be needed in the future,
> > > useful for out-of-tree debug code"?
> >
> > It is possible that I got it a wrong way on arm. The NMI buffe
On Fri 2015-12-18 10:18:08, Daniel Thompson wrote:
> On 11/12/15 23:26, Jiri Kosina wrote:
> >On Fri, 11 Dec 2015, Russell King - ARM Linux wrote:
> >
> >>I'm personally happy with the existing code, and I've been wondering why
> >>there's this effort to apply further cleanups - to me, the changelo
On Fri, Dec 18, 2015 at 12:29:02PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 18, 2015 at 10:18:08AM +, Daniel Thompson wrote:
> > I'm not entirely sure that this is an improvement.
>
> What I do these days is delete everything in vprintk_emit() and simply
> call early_printk().
On that, whoe
On Fri, Dec 18, 2015 at 10:18:08AM +, Daniel Thompson wrote:
> I'm not entirely sure that this is an improvement.
What I do these days is delete everything in vprintk_emit() and simply
call early_printk().
Kill the useless kmsg buffer crap and locking, just pound bytes to the
UART registers w
On 11/12/15 23:26, Jiri Kosina wrote:
On Fri, 11 Dec 2015, Russell King - ARM Linux wrote:
I'm personally happy with the existing code, and I've been wondering why
there's this effort to apply further cleanups - to me, the changelogs
don't seem to make that much sense, unless we want to start u
On Tue, 15 Dec 2015 15:26:21 +0100 Petr Mladek wrote:
> > OK, thanks. So "not needed at present, might be needed in the future,
> > useful for out-of-tree debug code"?
>
> It is possible that I got it a wrong way on arm. The NMI buffer is
> usable there on two locations.
>
> First, the tempora
On Fri 2015-12-11 15:30:54, Andrew Morton wrote:
> On Fri, 11 Dec 2015 23:21:13 + Russell King - ARM Linux
> wrote:
>
> > On Fri, Dec 11, 2015 at 02:57:25PM -0800, Andrew Morton wrote:
> > > This is a bit messy. NEED_PRINTK_NMI is an added-on hack for one
> > > particular arm variant. From
On 11/12/15 23:21, Russell King - ARM Linux wrote:
As I explained when I did that work, the vast majority of ARM platforms
are unable to trigger anything like a NMI - the FIQ is something that's
generally a property of the secure monitor, and is not accessible to
Linux. However, there are platfo
On Fri, 11 Dec 2015 23:21:13 + Russell King - ARM Linux
wrote:
> On Fri, Dec 11, 2015 at 02:57:25PM -0800, Andrew Morton wrote:
> > This is a bit messy. NEED_PRINTK_NMI is an added-on hack for one
> > particular arm variant. From the changelog:
> >
> >"One exception is arm where the d
On Fri, 11 Dec 2015, Russell King - ARM Linux wrote:
> I'm personally happy with the existing code, and I've been wondering why
> there's this effort to apply further cleanups - to me, the changelogs
> don't seem to make that much sense, unless we want to start using
> printk() extensively in NMI
On Fri, Dec 11, 2015 at 02:57:25PM -0800, Andrew Morton wrote:
> This is a bit messy. NEED_PRINTK_NMI is an added-on hack for one
> particular arm variant. From the changelog:
>
>"One exception is arm where the deferred printing is used for
> printing backtraces even without NMI. For th
On Fri, 11 Dec 2015 13:41:59 +0100 Petr Mladek wrote:
> On Fri 2015-12-11 12:10:02, Geert Uytterhoeven wrote:
> > On Wed, Dec 9, 2015 at 2:21 PM, Petr Mladek wrote:
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -866,6 +866,28 @@ config LOG_CPU_MAX_BUF_SHIFT
> > >
On Fri, Dec 11, 2015 at 1:41 PM, Petr Mladek wrote:
> On Fri 2015-12-11 12:10:02, Geert Uytterhoeven wrote:
>> On Wed, Dec 9, 2015 at 2:21 PM, Petr Mladek wrote:
>> > --- a/init/Kconfig
>> > +++ b/init/Kconfig
>> > @@ -866,6 +866,28 @@ config LOG_CPU_MAX_BUF_SHIFT
>> > 13 =>
On Friday 11 December 2015 13:41:59 Petr Mladek wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index efcff25a112d..61cfd96a3c96 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -870,7 +870,7 @@ config NMI_LOG_BUF_SHIFT
> int "Temporary per-CPU NMI log buffer size (12 => 4KB, 13 =>
On Fri 2015-12-11 12:10:02, Geert Uytterhoeven wrote:
> On Wed, Dec 9, 2015 at 2:21 PM, Petr Mladek wrote:
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -866,6 +866,28 @@ config LOG_CPU_MAX_BUF_SHIFT
> > 13 => 8 KB for each CPU
> > 12 => 4 KB fo
On Wed, Dec 9, 2015 at 2:21 PM, Petr Mladek wrote:
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -866,6 +866,28 @@ config LOG_CPU_MAX_BUF_SHIFT
> 13 => 8 KB for each CPU
> 12 => 4 KB for each CPU
>
> +config NMI_LOG_BUF_SHIFT
> + int "Temporary
19 matches
Mail list logo