From owner-freebsd-arm@freebsd.org Thu Jul 30 09:32:04 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1DEC9AEA06 for ; Thu, 30 Jul 2015 09:32:04 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F62C165 for ; Thu, 30 Jul 2015 09:32:04 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by iggf3 with SMTP id f3so29691754igg.1 for ; Thu, 30 Jul 2015 02:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xoI4VmPwq7GWlLULcExGGef2RtLz95zl5vLdxWx52dE=; b=t65lghxGl1zo32zkoqcebMk2AzPtkYFSGJS7/fzga9QafJlESbxmtNdG05nA4my0qs EjoB6MyP9K5nTir21SrZnJreX8NjsJASwntUZNBEnqHZR7VemkOpo0/LaKGZsk2XWXNT 153PXfffO6dANfe/s8+K9sWX/34w25JcEmAEaJ7m4c86NlxCf5bbOGgXsfTeeZn7CkLR Xb+PgO6ADqgXhF9pTUMCS4qxWDpgpa+KPMN4Ju9WfBfr2mh5/dz4vOCjh5Ywrz+TRVbD znDDEOrfVqhmjTixYG9ZDtslq3oqtUPTp+N/trN7T6eDA7ecr3gyL058a8cjjBGQyEcI txeQ== MIME-Version: 1.0 X-Received: by 10.50.2.9 with SMTP id 9mr3362745igq.42.1438248723731; Thu, 30 Jul 2015 02:32:03 -0700 (PDT) Received: by 10.64.148.84 with HTTP; Thu, 30 Jul 2015 02:32:03 -0700 (PDT) In-Reply-To: <20150729154516.GH78154@funkthat.com> References: <55A7D8CE.4020809@selasky.org> <55B23276.8090703@selasky.org> <55B73113.2020308@selasky.org> <55B8AB76.7030603@selasky.org> <55B8B297.1010008@selasky.org> <20150729154516.GH78154@funkthat.com> Date: Thu, 30 Jul 2015 11:32:03 +0200 Message-ID: Subject: Re: [RPI-B] [HEADS UP] DWC OTG TX path optimisation for 11-current From: Svatopluk Kraus To: John-Mark Gurney Cc: Hans Petter Selasky , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 09:32:04 -0000 On Wed, Jul 29, 2015 at 5:45 PM, John-Mark Gurney wrote: > Svatopluk Kraus wrote this message on Wed, Jul 29, 2015 at 13:52 +0200: >> On Wed, Jul 29, 2015 at 1:01 PM, Hans Petter Selasky wrote: >> > On 07/29/15 12:42, Svatopluk Kraus wrote: >> >> >> >> On Wed, Jul 29, 2015 at 12:31 PM, Hans Petter Selasky >> >> wrote: >> >>> >> >>> On 07/29/15 12:08, Svatopluk Kraus wrote: >> >>>> >> >>>> >> >>>> On Tue, Jul 28, 2015 at 9:36 AM, Hans Petter Selasky >> >>>> wrote: >> >>>>> >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> Can you test this: >> >>>>> >> >>>>> https://svnweb.freebsd.org/changeset/base/285935 >> >>>>> >> >>>> >> >>>> I'm hunting some strange behaviour slowdowning my set RPI2 - usb3 hub >> >>>> - usb3 disk during buildworld, but I have noticed the following: >> >>>> >> >>>> make -j6 buildworld >> >>>> >> >>>> before r285935 -> 60145.29 real 350932.67 user 36402.54 sys >> >>>> after r285935 -> 67831.38 real 196310.43 user 19135.73 sys >> >>>> >> >>>> The kernel before r285935 was day or two older. >> >>>> >> >>>> These are just one-run times, however the difference is quite big. The >> >>>> change r285935 could influence the thing I'm investigating so it's >> >>>> worse now, but still ... >> >>>> >> >>> >> >>> Regarding build times you should also take "r285068" into account. >> >>> >> >> >> >> Yes, I know about that. The r285068 was applied in both kernels. >> >> >> > >> > Hi, >> > >> > The "sys" and "user" times are down. While the "real" time is up. That means >> > more sleeping??? There is a knob in "hw.usb.umass.throttle" which you can >> > set to slow down the disk access. Maybe it's reading files faster than >> > before and then starts swapping? >> > >> >> >> The "sys" and "user" times are not reliable much. It was reported on >> arm a few times. However, I wanted to report what I noticed just to >> let anybody know about it. Maybe somebody would test r285068 for usb >> disk too. I need to hunt down my problem firstly to be more sure about >> this. >> >> Just for your information, when I start buildworld, the system >> responds very fast (console, ssh). After about one hour, it starts to >> print the following warnings: >> >> smsc0: warning: MII is busy >> smsc0: warning: Failed to write register 0x114 >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x118 >> smsc0: warning: Failed to write register 0x114 >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to write register 0x114 >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to read register 0x114 >> smsc0: warning: MII is busy >> smsc0: warning: Failed to write register 0x114 >> smsc0: warning: Failed to read register 0x114 > > Are these messages almost constantly scrolling on the terminal? Is > your console also a serial console? If so, then it's likely that > these printf's are what is causing things to be slow... If you > recompiled w/o those, then it's likely that your system won't be > slow anymore.. The answer is no. The shortest period is about a second. Most often, it's several seconds. I was wondering if each of MII request is failing, so I added a counter to them. Hundreds of requests successes before one fails. > > Though the real fix is to figure out why these messages are happen > and fix them... I do not think that it's problem of smsc driver. The messages are just indicator that something else (it's most propably usb disk related) is generating big load so other clients on usb are restrained. However, when it happens, this big load does not stop even if system is "idle", so it looks that it's generated "internally" somewhere. For example, it could be a try to recover from some "problems" which never recovers. > >> and system responds very slow. When I stop buildworld (or when it >> finishes), the warnings are still printed and system is still slow. >> Even after several hours. When I disconnect everything (except the >> disk itself), it does not help. When I set hw.usb.dwc_otg.debug=1, >> there is quite a lot debug printing. Just now, I'm trying to know who >> is responsible for such big trafic (almost nothing is running in >> system). The generated load is so big that I'm not able to turn off >> the debug sometimes. >> >> Svata >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not."