From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934814AbbCPQPL (ORCPT ); Mon, 16 Mar 2015 12:15:11 -0400 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:49384 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933138AbbCPQPJ (ORCPT ); Mon, 16 Mar 2015 12:15:09 -0400 Date: Mon, 16 Mar 2015 16:14:49 +0000 From: Russell King - ARM Linux To: Tony Lindgren Cc: Pavel Machek , Pali =?iso-8859-1?Q?Roh=E1r?= , Rob Herring , Will Deacon , Ivaylo Dimitrov , Sebastian Reichel , Andreas =?iso-8859-1?Q?F=E4rber?= , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Nicolas Pitre , Arnd Bergmann Subject: Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision Message-ID: <20150316161449.GJ8656@n2100.arm.linux.org.uk> References: <201502271645.58765@pali> <1425052528-18995-1-git-send-email-pali.rohar@gmail.com> <20150302112836.GA27317@amd> <20150316154409.GQ5264@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150316154409.GQ5264@atomide.com> 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 On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > * Pavel Machek [150302 03:32]: > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > > > Pali Rohár (2): > > > arm: devtree: Set system_rev from DT revision > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > Acked-by: Pavel Machek > > Are these queued somewhere now? Sounds like this is the last pending > issue for n900 to use legacy user space with current mainline kernels, > so I'd like to get these in so we can get closer to making omap3 boot > in device tree only mode. Not that I know of. As everyone is aware, patches need to be in my patch system if they want me to apply them - which would've been especially important as I was away from kernel stuff for a week at the start of March (for medical reasons) and I can't be expected to track the status of stuff which is buried behind 1000+ extra mails. In any case, I'm currently not accepting /any/ patches into my tree at present; I'm chasing a horrid instability on one of my test platforms which is making it impossible to tell whether any particular change or changes in my tree is responsible or not for it. It doesn't seem to be a hardware failure (if it was, I'd simply take the board out of the nightly test system.) It's quite literally taking hours to figure out what's going on - I've been on this for about 12 hours now and still not much closer to knowing what's causing it (other than I know that -rc1 plus my queue seems to be fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So something I'm already carrying seems to be responsible, but each time I identify a particular patch and drop _just_ that change, I find that the problem is back when I try my queue minus the bad changes. With a test cycle time of 20+ minutes (due to the number of boots required to make certain of a dependable result), this is /really/ slow progress. Right now, I can't be positively sure that /anything/ I have already merged isn't a factor in causing this problem, so I don't want to augment my tree with any additional patches which would upset my ability to move about in the tree, and get reproducable results from repeated testing. To merge something else will probably mean I'll have to start again from the beginning and the last 12 hours spent testing will have been wasted. Sorry. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Mon, 16 Mar 2015 16:14:49 +0000 Subject: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision In-Reply-To: <20150316154409.GQ5264@atomide.com> References: <201502271645.58765@pali> <1425052528-18995-1-git-send-email-pali.rohar@gmail.com> <20150302112836.GA27317@amd> <20150316154409.GQ5264@atomide.com> Message-ID: <20150316161449.GJ8656@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > * Pavel Machek [150302 03:32]: > > On Fri 2015-02-27 16:55:26, Pali Roh?r wrote: > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > > > Pali Roh?r (2): > > > arm: devtree: Set system_rev from DT revision > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > Acked-by: Pavel Machek > > Are these queued somewhere now? Sounds like this is the last pending > issue for n900 to use legacy user space with current mainline kernels, > so I'd like to get these in so we can get closer to making omap3 boot > in device tree only mode. Not that I know of. As everyone is aware, patches need to be in my patch system if they want me to apply them - which would've been especially important as I was away from kernel stuff for a week at the start of March (for medical reasons) and I can't be expected to track the status of stuff which is buried behind 1000+ extra mails. In any case, I'm currently not accepting /any/ patches into my tree at present; I'm chasing a horrid instability on one of my test platforms which is making it impossible to tell whether any particular change or changes in my tree is responsible or not for it. It doesn't seem to be a hardware failure (if it was, I'd simply take the board out of the nightly test system.) It's quite literally taking hours to figure out what's going on - I've been on this for about 12 hours now and still not much closer to knowing what's causing it (other than I know that -rc1 plus my queue seems to be fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So something I'm already carrying seems to be responsible, but each time I identify a particular patch and drop _just_ that change, I find that the problem is back when I try my queue minus the bad changes. With a test cycle time of 20+ minutes (due to the number of boots required to make certain of a dependable result), this is /really/ slow progress. Right now, I can't be positively sure that /anything/ I have already merged isn't a factor in causing this problem, so I don't want to augment my tree with any additional patches which would upset my ability to move about in the tree, and get reproducable results from repeated testing. To merge something else will probably mean I'll have to start again from the beginning and the last 12 hours spent testing will have been wasted. Sorry. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.