Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Jul 2015 11:32:03 +0200
From:      Svatopluk Kraus <onwahe@gmail.com>
To:        John-Mark Gurney <jmg@funkthat.com>
Cc:        Hans Petter Selasky <hps@selasky.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: [RPI-B] [HEADS UP] DWC OTG TX path optimisation for 11-current
Message-ID:  <CAFHCsPWEN7J=h-ZGYzW-OGajFV4UOcpumHp=JRnYOiz3GQ-OJw@mail.gmail.com>
In-Reply-To: <20150729154516.GH78154@funkthat.com>
References:  <55A7D8CE.4020809@selasky.org> <CAHNYxxMp9jGDbV-5=-cE6daR-O3eN5pdvO1s-=QfX=A9XYqYmA@mail.gmail.com> <55B23276.8090703@selasky.org> <CAHNYxxNc9uB62hHEv1PM9PcsGgUs=zsvNgatqLD0p%2BiiDA3Aiw@mail.gmail.com> <55B73113.2020308@selasky.org> <CAFHCsPVaPZpqXLS7OApa=Xz5VLnLjVpV5dYV8Pn2uHh1Lcz7Tg@mail.gmail.com> <55B8AB76.7030603@selasky.org> <CAFHCsPUMaYEwJsaGUFuw9yZi_5bmraSBsOYpRWvSeuebpXBJUA@mail.gmail.com> <55B8B297.1010008@selasky.org> <CAFHCsPVGLs8j6LAV%2Bg4rP_ueTOd8pUOupYFGvmgC3XGcJC720Q@mail.gmail.com> <20150729154516.GH78154@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 29, 2015 at 5:45 PM, John-Mark Gurney <jmg@funkthat.com> 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 <hps@selasky.org> wrote:
>> > On 07/29/15 12:42, Svatopluk Kraus wrote:
>> >>
>> >> On Wed, Jul 29, 2015 at 12:31 PM, Hans Petter Selasky <hps@selasky.org>
>> >> wrote:
>> >>>
>> >>> On 07/29/15 12:08, Svatopluk Kraus wrote:
>> >>>>
>> >>>>
>> >>>> On Tue, Jul 28, 2015 at 9:36 AM, Hans Petter Selasky <hps@selasky.org>
>> >>>> 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."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPWEN7J=h-ZGYzW-OGajFV4UOcpumHp=JRnYOiz3GQ-OJw>