From patchwork Mon Feb 27 19:43:41 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sam Ravnborg X-Patchwork-Id: 143254 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 7320BB6FA7 for ; Tue, 28 Feb 2012 06:44:01 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754876Ab2B0Tnq (ORCPT ); Mon, 27 Feb 2012 14:43:46 -0500 Received: from smtp.snhosting.dk ([87.238.248.203]:31098 "EHLO smtp.domainteam.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753957Ab2B0Tnn (ORCPT ); Mon, 27 Feb 2012 14:43:43 -0500 Received: from merkur.ravnborg.org (unknown [188.228.89.252]) by smtp.domainteam.dk (Postfix) with ESMTPA id 0BD23F1A16; Mon, 27 Feb 2012 20:43:42 +0100 (CET) Date: Mon, 27 Feb 2012 20:43:41 +0100 From: Sam Ravnborg To: Meelis Roos Cc: Tejun Heo , Grant Likely , Rob Herring , sparclinux@vger.kernel.org, Linux Kernel list , "David S. Miller" Subject: Re: OF-related boot crash in 3.3.0-rc3-00188-g3ec1e88 Message-ID: <20120227194341.GA1448@merkur.ravnborg.org> References: <20120220170603.GC7836@mtj.dyndns.org> <20120221010537.GA15898@dhcp-172-17-108-109.mtv.corp.google.com> <20120222174825.GA32694@google.com> <20120223185503.GI22536@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org On Mon, Feb 27, 2012 at 07:17:42PM +0200, Meelis Roos wrote: > > > > > Can you please try the following patch? If it still fails to boot, > > > > > please attach the failing log. Thank you. > > > > > > > > It works on E3500! Will try other machines tomorrow. > > > > > > Once confirmed, I'll push the patch through tip. It just hides the > > > underlying problem but we should be in no worse shape than before, > > > it's two line change so reproduing the problem again for proper > > > diagnosing isn't difficult, and we're getting a bit late in release > > > cycle already. > > > > It cured the V210 too but I could not test V100 since it's offline until > > monday. > > Tested V100 too, success! Hi Meelis. I have tried to cook up a small patch that verify the length of what we read - compared to the original length. Could you try to give this a quick spin and see if something turns up. I you have time it would be good to try on a box that worked before and one that was fixed by the patch from Tejun. I have not looked much at the of stuff - but this looked like the right place to start. I have no possibility to try it out myself... Sam --- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/of/pdt.c b/drivers/of/pdt.c index 07cc1d6..826204a 100644 --- a/drivers/of/pdt.c +++ b/drivers/of/pdt.c @@ -128,6 +128,10 @@ static struct property * __init of_pdt_build_one_prop(phandle node, char *prev, p->value = prom_early_alloc(p->length + 1); len = of_pdt_prom_ops->getproperty(node, p->name, p->value, p->length); + + if (len != p->length) + pr_err("prop: %s %d => %d", p->name, p->length, len); + if (len <= 0) p->length = 0; ((unsigned char *)p->value)[p->length] = '\0'; @@ -161,8 +165,13 @@ static char * __init of_pdt_get_one_property(phandle node, const char *name) len = of_pdt_prom_ops->getproplen(node, name); if (len > 0) { + int proplen; buf = prom_early_alloc(len); - len = of_pdt_prom_ops->getproperty(node, name, buf, len); + proplen = of_pdt_prom_ops->getproperty(node, name, buf, len); + + if (proplen != len) + pr_err("prop: %s %d => %d\n", name, len, proplen); + } return buf;