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()
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
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
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,
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
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
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
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
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.
>
>
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
> > >
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
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
> +
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
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
> >
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, 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
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
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
Testing has shown that the backtrace sometimes does not fit
into the 4kB temporary buffer that is used in NMI context.
The warnings are gone when I double the temporary buffer size.
This patch doubles the buffer size and makes it configurable.
Note that this problem existed even in the
19 matches
Mail list logo