Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755444AbbGEJKU (ORCPT ); Sun, 5 Jul 2015 05:10:20 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:37419 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751103AbbGEJKL (ORCPT ); Sun, 5 Jul 2015 05:10:11 -0400 Date: Sat, 4 Jul 2015 13:03:59 +0200 From: Ingo Molnar To: Steven Rostedt Cc: LKML , Thomas Gleixner , "H. Peter Anvin" , Greg Kroah-Hartman , David Cohen , Andy Shevchenko , Alan Cox , "Stuart R. Anderson" Subject: Re: [RFC][PATCH] x86: Allow early_printk to use console style param like 115200n8 Message-ID: <20150704110359.GA18107@gmail.com> References: <20150703181643.4fd4053d@grimm.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150703181643.4fd4053d@grimm.local.home> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2373 Lines: 61 * Steven Rostedt wrote: > When I enable early_printk on a kernel, I cut and paste the console= > input and add to earlyprintk parameter. But I notice recently that > ktest has not been detecting triple faults. The way it detects it, is > by seeing the kernel banner "Linux version .." with a different kernel > version pop up. Then I noticed that early printk was no longer working > on my console, which was why ktest was not seeing it. > > I bisected it down and it was added to 4.0 with this commit: > > commit ea9e9d802902 ("Specify PCI based UART for earlyprintk") Ugh, this commit changed x86 code but was not Cc:-ed to any x86 maintainer, and the title was pretty misleading as well... ( That patch should have been split into at least two parts: the generic earlyprintk changes affecting all modes, and the 'pciserial' enablement. Anyway, that's water down the bridge. ) > because it converted the simple_strtoul() that converts the baud number into a > kstrtoul(). The problem with this is, I had as my baud rate, 115200n8 > (acceptable for console=ttyS0), but because of the "n8", the kstrtoul() doesn't > parse the baud rate and returns an error, which sets the baud rate to the > default 9600. This explains the garbage on my screen. ugh. I bet it also breaks the earlyprintk=ttyS0..,keep format? > Now, earlyprintk= kernel parameter does not say it accepts that format. Thus, > one answer would simply be me changing my kernel parameters to remove the "n8" > since it isn't parsed anyway. But I wonder if other people run into this, and it > seems strange that the two consoles for serial accepts different input. So why not revert to the known-working simple_strtoul()? I don't see this as an improvement: > + /* > + * In case the input is like console with text after the baud > + * rate. e.g. 115200n8. kstrtoul() will error on such input. > + */ > + for (p = s; *p && isdigit(*p); p++) > + ; > + *p = 0; > + > if (kstrtoul(s, 0, &baud) < 0 || baud == 0) > baud = DEFAULT_BAUD; Over the old: baud = simple_strtoul(s, &e, 0); Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/