From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Senozhatsky Subject: Re: Serial console is causing system lock-up Date: Thu, 7 Mar 2019 11:22:54 +0900 Message-ID: <20190307022254.GB4893@jagdpanzerIV> References: <20190306152218.eocv4zulf7tv2mkc@pathway.suse.cz> <20190306163003.GA31858@mit.edu> <20190306171943.12345598@oasis.local.home> <87ftrzbp3y.fsf@linutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <87ftrzbp3y.fsf@linutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: John Ogness Cc: Petr Mladek , Nigel Croxon , "Theodore Y. Ts'o" , Greg Kroah-Hartman , Steven Rostedt , Sergey Senozhatsky , dm-devel@redhat.com, Mikulas Patocka , linux-serial@vger.kernel.org List-Id: linux-serial@vger.kernel.org On (03/06/19 23:43), John Ogness wrote: > > Sounds like another aurgment for the new printk design. > > Assuming the bad checksum messages are considered an emergency (for > example, at least loglevel KERN_WARN), then the new printk design would > print those messages synchronously to the slow serial line in the > context of the driver as the driver is producing them. I wonder if we have several CPU doing the checksum verification. New sync printk mechanism has a Big-Konsole-spin-Lock, all CPUs that want to printk() should line up and wait, in whatever context they currently are. > There wouldn't be a lock-up, but it would definitely slow down the > driver. The situation of "messages being produced faster than the kernel > can write them" would never exist because the printk() call will only > return after the writing is completed. If the serial console is a really slow one and we have a CPU in atomic context spinnig on prb_lock, while the prb_lock is always acquired by other CPUs, then it may look like a lock-up scenario. -ss