From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: Regression due to 7ff9554 "printk: convert byte-buffer to variable-length record buffer" Date: Thu, 10 May 2012 14:13:04 -0600 Message-ID: <4FAC2150.2060804@wwwdotorg.org> References: <4FAAB815.5040001@wwwdotorg.org> <4FAC1D09.1070004@wwwdotorg.org> <4FAC2085.7030002@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from avon.wwwdotorg.org ([70.85.31.133]:33026 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752449Ab2EJUNH (ORCPT ); Thu, 10 May 2012 16:13:07 -0400 In-Reply-To: <4FAC2085.7030002@wwwdotorg.org> Sender: linux-next-owner@vger.kernel.org List-ID: To: Kay Sievers Cc: Greg Kroah-Hartman , William Douglas , "linux-kernel@vger.kernel.org" , linux-next@vger.kernel.org On 05/10/2012 02:09 PM, Stephen Warren wrote: > On 05/10/2012 02:06 PM, Kay Sievers wrote: >> On Thu, May 10, 2012 at 9:54 PM, Stephen Warren wrote: >>> On 05/09/2012 12:31 PM, Stephen Warren wrote: >>>> For me, next-20120508 prints nothing when booted, and I think also >>>> hangs. To solve this, I reverted: >>>> >>>> 7ff9554 printk: convert byte-buffer to variable-length record buffer >>>> >>>> In order to build, I also had to revert: >>>> >>>> c4e00da driver-core: extend dev_printk() to pass structured data >>>> >>>> Note: I'm running on an ARM system using a serial console, with >>>> earlyprintk enabled. >>> >>> This issue still occurs in next-20120510. >>> >>> I've tracked it down to the assignment of msg->ts_nsec near the end of >>> log_store(). If I comment this out, everything works. The problem is the >>> assignment, not the call to local_clock(): >>> >>> fails: >>> msg->ts_nsec = local_clock(); >>> fails: >>> msg->ts_nsec = 0;//local_clock(); >>> works: >>> //msg->ts_nsec = local_clock(); >> >> Weird. >> >> What happens if you change it to: >> cpu_clock(logbuf_cpu); >> ? >> >> If it works, the timestamps look ok? > > I doubt that would work - after all, assigning 0 fails, but not > performing the assignment at all works. But, I'll go try it... Calling cpu_clock() instead of local_clock() fails in the same way.