On Fri 2024-12-13 13:46:04, Yafang Shao wrote:
> Since the task->comm is guaranteed to be NUL-ternimated, we can print it
> directly. Add a new vsnprintf format specifier "%pTN" to print task comm,
> where 'p' represents the task Pointer, 'T' stands for Task, and 'N' denots
> Name. With this abstra
On Mon 2024-09-09 09:53:59, Uros Bizjak wrote:
> Substitute the inclusion of header with
> to allow the removal of legacy inclusion
> of from .
>
> Signed-off-by: Uros Bizjak
I have just acked v1 and missed that there already is v2.
Just for record:
Acked-by: Petr Mladek
On Wed 2024-02-28 09:32:37, Rasmus Villemoes wrote:
> On 27/02/2024 19.32, Ville Syrjälä wrote:
> > On Tue, Feb 27, 2024 at 10:38:10AM +0100, Rasmus Villemoes wrote:
> >> On 26/02/2024 15.57, Jani Nikula wrote:
> So if we really want to go down this road, I think it should be
> something like %pX{d
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 the
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 anywhere. Includi
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 loc
Anyway
it will not prevent the deadlock.
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:
Fr
On Wed 2019-05-08 10:17:12, Daniel Vetter wrote:
> On Mon, May 06, 2019 at 01:24:48PM +0200, Petr Mladek wrote:
> > On Mon 2019-05-06 11:38:13, Daniel Vetter wrote:
> > > On Mon, May 06, 2019 at 10:26:28AM +0200, Petr Mladek wrote:
> > > > On Mon 2019-05-
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 loc
On Mon 2019-05-06 11:38:13, Daniel Vetter wrote:
> On Mon, May 06, 2019 at 10:26:28AM +0200, Petr Mladek wrote:
> > On Mon 2019-05-06 10:16:14, Petr Mladek wrote:
> > > On Mon 2019-05-06 09:45:53, Daniel Vetter wrote:
> > > > console_trylock, called from within pri
On Mon 2019-05-06 10:16:14, Petr Mladek wrote:
> On Mon 2019-05-06 09:45:53, 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 i
On Mon 2019-05-06 09:45:53, 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 loc
On Mon 2019-05-06 09:45:53, 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 loc
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 loc
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
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
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
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: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 the
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 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 .lock
>
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, D
24 matches
Mail list logo
