On Wed 2024-07-03 09:57:26, Jocelyn Falempe wrote:
>
>
> On 02/07/2024 22:29, Kees Cook wrote:
> > On Tue, Jul 02, 2024 at 02:26:04PM +0200, Jocelyn Falempe wrote:
> > > kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
> > > callback.
> > > This patch adds a new struct
n't update the forward
>declaration of oops_to_nvram()
>
> Signed-off-by: Jocelyn Falempe
Looks good to me. With the minor fixes suggested by Kees:
Acked-by: Petr Mladek
Best Regards,
Petr
On Tue 2024-06-25 14:39:29, Jocelyn Falempe wrote:
> kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
> callback.
> This patch adds a new parameter "const char *desc" to the kmsg_dumper
> dump() callback, and update all drivers that are using it.
>
> To avoid updating all
On Fri 2022-11-18 12:22:58, Petr Mladek wrote:
> On Wed 2022-11-16 17:27:12, John Ogness wrote:
> > This is v5 of a series to prepare for threaded/atomic
> > printing. v4 is here [0]. This series focuses on reducing the
> > scope of the BKL console_lock. It achieves this by
On Wed 2022-11-16 17:27:12, John Ogness wrote:
> This is v5 of a series to prepare for threaded/atomic
> printing. v4 is here [0]. This series focuses on reducing the
> scope of the BKL console_lock. It achieves this by switching to
> SRCU and a dedicated mutex for console list iteration and
>
sole_force_preferred_locked(struct console *con)
>
> /* Only the new head can have CON_CONSDEV set. */
> console_srcu_write_flags(cur_pref_con, cur_pref_con->flags &
> ~CON_CONSDEV);
> - hlist_add_behind_rcu(>node, console_list.first);
> + hlist_add_head_rcu(>node, _list);
> }
> EXPORT_SYMBOL(console_force_preferred_locked);
With this change:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Mon 2022-11-07 15:22:31, John Ogness wrote:
> With commit 9e124fe16ff2("xen: Enable console tty by default in domU
> if it's not a dummy") a hack was implemented to make sure that the
> tty console remains the console behind the /dev/console device. The
> main problem with the hack is that,
On Thu 2022-11-10 17:09:12, John Ogness wrote:
> On 2022-11-10, Petr Mladek wrote:
> >> +void console_force_preferred_locked(struct console *con)
> >> +{
> >> + struct console *cur_pref_con;
> >> +
> >> + if (!console_i
On Mon 2022-11-07 15:22:31, John Ogness wrote:
> With commit 9e124fe16ff2("xen: Enable console tty by default in domU
> if it's not a dummy") a hack was implemented to make sure that the
> tty console remains the console behind the /dev/console device. The
> main problem with the hack is that,
On Thu 2022-10-27 15:41:23, John Ogness wrote:
> On 2022-10-27, Petr Mladek wrote:
> >> - if (c) {
> >> - unregister_console(c);
> >> - c->flags |= CON_CONSDEV;
> >> - c->flags &= ~CON_PRINTBUFFER; /* don't
On Wed 2022-10-19 17:02:00, John Ogness wrote:
> With commit 9e124fe16ff2("xen: Enable console tty by default in domU
> if it's not a dummy") a hack was implemented to make sure that the
> tty console remains the console behind the /dev/console device. The
> main problem with the hack is that,
On Wed 2022-10-19 17:01:46, John Ogness wrote:
> Since the console_lock is not being used for anything other than
> safe console list traversal, use srcu console list iteration instead.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
> ---
> drivers/video/fbdev
On Wed 2021-11-10 10:37:26, Daniel Vetter wrote:
> On Tue, Nov 09, 2021 at 10:38:47PM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 09, 2021 at 12:06:48PM -0800, Sultan Alsawaf wrote:
> > > Hi,
> > >
> > > I encountered a printk deadlock on 5.13 which appears to still affect the
> > > latest
> >
On Wed 2021-03-03 15:34:09, Petr Mladek wrote:
> Hi,
>
> the following warning is filling my kernel log buffer
> with 5.12-rc1+ kernels:
>
> [ 941.070598] WARNING: CPU: 0 PID: 11 at drivers/gpu/drm/ttm/ttm_bo.c:139
> ttm_bo_move_to_lru_tail+0x1ba/0x210
> [ 94
Hi,
the following warning is filling my kernel log buffer
with 5.12-rc1+ kernels:
[ 941.070598] WARNING: CPU: 0 PID: 11 at drivers/gpu/drm/ttm/ttm_bo.c:139
ttm_bo_move_to_lru_tail+0x1ba/0x210
[ 941.070601] Modules linked in:
[ 941.070603] CPU: 0 PID: 11 Comm: kworker/0:1 Kdump: loaded
On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
> +Cc: Sakari and printk people
>
> On Mon, Feb 15, 2021 at 4:28 PM Christian König
> wrote:
> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > > We have already few similar implementation and a lot of code that can
> > > benefit
> > > of
On Tue 2021-02-16 09:37:45, Thomas Zimmermann wrote:
> Hi
>
> Am 15.02.21 um 12:40 schrieb Sakari Ailus:
> > Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
> > large number of temporary variables at the same time.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> >
On Mon 2021-02-15 13:40:30, Sakari Ailus wrote:
> Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
> large number of temporary variables at the same time.
>
> Signed-off-by: Sakari Ailus
Reviewed-by: Petr Mladek
I wonder if I could this via printk tree.
On Mon 2021-02-15 13:40:29, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.
>
> Signed-off-by: Sakari Ailus
Reviewed-by: Petr Mladek
I am curious whether I could take this via printk tree or if Mauro
would pr
gt; I count in numbers... albeit the hexadecimal number there starts from zero.
> >
> > I guess both would work though.
> >
> > 0123 would be consistent.
>
> Since letters can be printed the above is confusing a bit. I think XY12 is
> closer to the reality than 0123
On Fri 2021-02-12 13:28:56, Sakari Ailus wrote:
> On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote:
> > On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> > > Hi Andy,
> > >
> > > On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> &
On Mon 2021-02-08 22:09:02, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++-
> 1 file changed, 21 insertions(+),
On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> Hi Andy,
>
> On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Feb 8, 2021 at
On Thu 2021-02-04 06:51:09, Masahiro Yamada wrote:
> On Thu, Feb 4, 2021 at 12:23 AM Petr Mladek wrote:
> >
> > On Tue 2021-02-02 09:44:22, John Ogness wrote:
> > > On 2021-02-02, Masahiro Yamada wrote:
> > > > CONSOLE_LOGLEVEL_DEFA
-by: Miroslav Benes
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue 2021-02-02 09:44:22, John Ogness wrote:
> On 2021-02-02, Masahiro Yamada wrote:
> > CONSOLE_LOGLEVEL_DEFAULT is nothing more than a shorthand of
> > CONFIG_CONSOLE_LOGLEVEL_DEFAULT.
> >
> > When you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT from Kconfig, almost
> > all objects are rebuilt
On Tue 2021-01-26 15:25:16, Jessica Yu wrote:
> +++ Christoph Hellwig [21/01/21 08:49 +0100]:
> > To uncouple the livepatch code from module loader internals move a
> > slightly refactored version of klp_find_object_module to module.c
> > This allows to mark find_module static and removes one of
On Thu 2021-01-21 08:49:49, Christoph Hellwig wrote:
> Merge three calls to klp_is_module (including one hidden inside
> klp_find_object_module) into a single one to simplify the code a bit.
>
> Signed-off-by: Christoph Hellwig
> ---
> kernel/livepatch/core.c | 18 +-
> 1 file
On Thu 2020-12-10 16:08:05, Andy Shevchenko wrote:
> On Thu, Dec 10, 2020 at 03:55:27PM +0200, Sakari Ailus wrote:
> > On Thu, Dec 10, 2020 at 03:05:02PM +0200, Andy Shevchenko wrote:
> > > My concerns are:
> > > - not so standard format of representation (why not to use
> > > string_escape_mem()
On Fri 2020-11-13 12:54:41, Sakari Ailus wrote:
> Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by fourccs. The fourcc encoding is the same for both
> so the same implementation can be used.
>
> Suggested-by: Mauro Carvalho Chehab
>
b
> Signed-off-by: Sakari Ailus
The last version looks fine to me.
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon 2020-09-28 12:25:59, Peter Zijlstra wrote:
> On Mon, Sep 28, 2020 at 06:04:23PM +0800, Chengming Zhou wrote:
>
> > Well, you are lucky. So it's a problem in our printk implementation.
>
> Not lucky; I just kicked it in the groin really hard:
>
>
On Thu 2019-07-25 13:21:12, Brendan Higgins wrote:
> On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek wrote:
> >
> > On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> > > Quoting Brendan Higgins (2019-07-22 15:30:49)
> > > > On Mon, Jul 22,
On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> Quoting Brendan Higgins (2019-07-22 15:30:49)
> > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd wrote:
> > >
> > >
> > > What's the calling context of the assertions and expectations? I still
> > > don't like the fact that string stream needs to
On Fri 2019-05-10 17:20:15, Daniel Vetter wrote:
> On Fri, May 10, 2019 at 11:28 AM Petr Mladek wrote:
> >
> > On Thu 2019-05-09 22:06:33, Daniel Vetter wrote:
> > > console_trylock, called from within printk, can be called from pretty
> > > much anywher
lock.
The only way to avoid the deadlock is to use printk_deferred()
with the current printk() code.
Finally, I have recently worked on similar problem with dying system.
I sent the following patch for testing. I wonder if it might be
acceptable upstream:
From: Petr Mladek
Subject: sched/x86
On Thu 2019-05-09 22:06:33, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then
On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then
On Mon 2019-05-06 09:11:37, Daniel Vetter wrote:
> On Fri, May 3, 2019 at 5:14 PM Petr Mladek wrote:
> > On Thu 2019-05-02 16:16:43, Daniel Vetter wrote:
> > > console_trylock, called from within printk, can be called from pretty
> > > much anywhere. Including try_to_wa
On Thu 2019-05-02 16:16:43, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then
On Sat 2019-04-13 09:22:05, Alastair D'Silva wrote:
> > -Original Message-
> > From: Petr Mladek
> > Sent: Friday, 12 April 2019 11:48 PM
> > To: Alastair D'Silva
> > Cc: alast...@d-silva.org; Jani Nikula ;
> Joonas
> > Lahtinen ; Rodrigo
On Sat 2019-04-13 09:28:03, Alastair D'Silva wrote:
> > -Original Message-
> > From: Petr Mladek
> > Sent: Saturday, 13 April 2019 12:04 AM
> > To: Alastair D'Silva
> > Cc: alast...@d-silva.org; Jani Nikula ;
> Joonas
> > Lahtinen ; Rodrigo
On Sat 2019-04-13 09:31:27, Alastair D'Silva wrote:
> > -Original Message-
> > From: Petr Mladek
> > Sent: Saturday, 13 April 2019 12:12 AM
> > To: Alastair D'Silva
> > Cc: alast...@d-silva.org; Jani Nikula ;
> Joonas
> > Lahtinen ; Rodrigo
On Wed 2019-04-10 13:17:18, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Some buffers may only be partially filled with useful data, while the rest
> is padded (typically with 0x00 or 0xff).
>
> This patch introduces flags which allow lines of padding bytes to be
> suppressed, making
On Wed 2019-04-10 13:17:19, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
On Wed 2019-04-10 13:17:17, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> With modern high resolution screens, we can display more data, which makes
> life a bit easier when debugging.
I have quite some doubts about this feature.
We are talking about more than 256 characters per-line. I
On Fri 2019-01-11 15:04:32, Sergey Senozhatsky wrote:
> On (01/10/19 14:03), Prarit Bhargava wrote:
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -649,11 +649,14 @@ static void fbcon_prepare_logo(struct vc_data *vc,
> > struct fb_info *info,
> > kfree(save);
> > }
> >
> > +
On Thu 2018-12-20 17:31:57, Bartlomiej Zolnierkiewicz wrote:
>
> [ added Petr & Sergey to Cc: ]
>
> Hi,
>
> On 10/30/2018 04:44 PM, Prarit Bhargava wrote:
> > On text-based systems the 'quiet' boot option will show printk levels
> > higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux
On Thu 2018-11-29 19:29:24, Luis Chamberlain wrote:
> On Wed, Nov 28, 2018 at 11:36:20AM -0800, Brendan Higgins wrote:
> > A number of test features need to do pretty complicated string printing
> > where it may not be possible to rely on a single preallocated string
> > with parameters.
> >
> >
On Tue 2018-08-21 00:14:35, Dmitry Safonov wrote:
> Hi Petr, thanks for review,
>
> On Wed, 2018-08-15 at 17:10 +0200, Petr Mladek wrote:
> > On Tue 2018-07-03 23:56:28, Dmitry Safonov wrote:
> > > Currently ratelimit_state is protected with spin_lock. If the .l
On Tue 2018-07-03 23:56:28, Dmitry Safonov wrote:
> Currently ratelimit_state is protected with spin_lock. If the .lock is
> taken at the moment of ___ratelimit() call, the message is suppressed to
> make ratelimiting robust.
>
> That results in the following issue issue:
> CPU0
On Wed 2018-07-18 19:49:10, Andy Shevchenko wrote:
> On Tue, Jul 17, 2018 at 3:59 AM, Dmitry Safonov wrote:
> > I would be glad if someone helps/bothers to review the change :C
> >
>
> Perhaps Petr and / or Steven can help you.
> > Thanks,
> > Dmitry
> >
> > On Tue, 2018-07-03 at 23:56 +0100,
rement it after leaving the CS. Setting ignore_console_lock_warning
> is only for debugging. Regular operation should not manipulate it.
>
> Acknoledgements: This patch is based on an earlier version by Steven
> Rostedt. The use of atomic increment/decrement was suggested by Petr
> Mladek.
ration avoid the noise.
>
> v3:
> - manipulate ignore_console_lock_warning with atomic_{inc,dec}
> v2:
> - restore ignore_console_lock_warning if lock_fb_info() fails
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Petr Mladek
I have vacation the following two w
On Wed 2018-07-18 11:30:02, Thomas Zimmermann wrote:
> If the console is unlocked during registration, the console subsystem
> generates significant amounts of warnings, which obfuscate actual
> debugging messages. Setting ignore_console_lock_warning while debugging
> console registration avoid
can
> > be set by drivers to ignore the warning in order to do debugging.
> >
> > Link: http://lkml.kernel.org/r/717e6337-e7a6-7a92-1c1b-8929a2569...@suse.de
> > Reviewed-by: Hans de Goede
> > Acked-by: Sergey Senozhatsky
> > Signed-off-by: Steven Rostedt (VM
s de Goede
Acked-by: Petr Mladek
Best Regards,
Petr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
uggested at
http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html
I am not familiar with the code. But the change looks sane
and we need something fast at this stage of 3.18 development.
Suggested-by: Helge Deller
Signed-off-by: Petr Mladek
Tested-by: Petr Mladek
---
drivers/gpu/drm/rad
59 matches
Mail list logo
