From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Rowand Subject: Re: linux-3.6.11-rt30 smoke test on ARM Date: Thu, 21 Mar 2013 13:26:31 -0700 Message-ID: <514B6CF7.4030901@am.sony.com> References: <51396143.5060108@am.sony.com> <51396306.6090902@am.sony.com> <20130311173424.GB22286@linutronix.de> <513FCBD3.4@am.sony.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Sebastian Andrzej Siewior , Thomas Gleixner , "linux-kernel@vger.kernel.org" , "linux-rt-users@vger.kernel.org" To: unlisted-recipients:; (no To-header on input) Return-path: Received: from mail-db8lp0187.outbound.messaging.microsoft.com ([213.199.154.187]:1876 "EHLO db8outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753007Ab3CUU0o (ORCPT ); Thu, 21 Mar 2013 16:26:44 -0400 In-Reply-To: <513FCBD3.4@am.sony.com> Sender: linux-rt-users-owner@vger.kernel.org List-ID: On 03/12/13 17:44, Frank Rowand wrote: > On 03/11/13 10:34, Sebastian Andrzej Siewior wrote: >> * Frank Rowand | 2013-03-07 20:03:18 [-0800]: >> >>> panda boot often fails due to a usb timeout, while sending a command on >>> behalf of the smsc95xx ethernet driver. >>> >>> This patch is a temporary hack to force a retry when the timeout occurs. >> >> It looks like you overrun the chip for some reason. Can you reproduce it >> on mainline? They added a few delayes on register read() it might do the >> trick. > > Yes, I can reproduce it on mainline. > > Here is the current state of my debugging: > > The problem usually occurs within three boot attempts. But it has also > taken eight boot attempts to see the problem. I do not know what the > maximum number of boots is required to see the problem, so I can not > state with certainty that a given kernel version does not have the > problem. If the boot fails then I can state with certainty that the > given kernel version has the problem. > > Given that level of uncertainty, I know: > > v3.5 does not appear to have the problem > v3.6-rc1 has the problem > v3.6 has the problem > v3.7 has the problem > v3.8 does not appear to have the problem > v3.9-rc1 fails to build > > I thought I had bisected the problem to a specific commit, but wanting > to be sure of it, I did extra boots of what should have been the last > good commit. On the 7th boot, that kernel version had the problem. > > I'll probably redo the bisect, but have not had time to do so yet. I did the bisect again, with more boot tests per bisect point, and found the commit to blame. Hopefully the problem will be resolved in the thread where I report the bisect: https://lkml.org/lkml/2013/3/20/742 > > The problem manifests as a timeout from at least two different locations > in drivers/net/usb/smsc95xx.c: > > > 656 static int smsc95xx_set_mac_address(struct usbnet *dev) > 657 { > ... > 663 ret = smsc95xx_write_reg(dev, ADDRL, addr_lo); > 664 if (ret < 0) { > 665 netdev_warn(dev->net, "Failed to write ADDRL: %d\n", ret); > 666 return ret; > 667 } > > > 751 static int smsc95xx_reset(struct usbnet *dev) > 752 { > ... > 783 write_buf = PM_CTL_PHY_RST_; > 784 ret = smsc95xx_write_reg(dev, PM_CTRL, write_buf); > 785 if (ret < 0) { > 786 netdev_warn(dev->net, "Failed to write PM_CTRL: %d\n", ret); > 787 return ret; > 788 } > > > Some of the other smsc95xx_write_reg() calls in smsc95xx_reset() are protected with > checks for timeout, with up to 100 retries. I do not know if this one should have > the same protection. > > -Frank