[lkml]   [2017]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage
On Mon 2017-04-10 13:53:39, Sergey Senozhatsky wrote:
> On (04/09/17 12:12), Pavel Machek wrote:
> [..]
> > > a side note,
> > > that's rather unclear to me how would "message delayed" really help.
> > > if your system hard-lockup so badly and there are no printk messages
> > > even from NMI watchdog, then we won't be able to print that message.
> >
> > We are talking about
> >
> > printk("unusual condition");
> > do_something_clever(); /* Which unfortunately hard-crashes the machine */
> >
> > that works with my proposal, but not with yours. Seen it happen many
> > times before.
> I see your point, sure.
> I can't completely agree on "that works with my proposal, but not with yours."
> on SMP system this would be true only if no other CPU holds the console_sem
> at the time we call printk(). (skipping irrelevant cases when we have suspended
> console or !online CPU and !CON_ANYTIME console). and there is nothing that
> makes "no other CPU holds the console_sem" always true on SMP system at any
> given point in time. so no, "A always works, B never works" is not
> accurate.

Ok, you are right. OTOH the common case is console_sem is unlocked (at
least on systems I develop on).

> but, once again, I see your point.

Good. Does that mean that the next version of patches will work ok in
that case?
(cesky, pictures)
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2017-04-10 20:49    [W:0.180 / U:1.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site