Date: Thu, 3 Sep 2015 16:16:18 +0200 From: Svatopluk Kraus <onwahe@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: DWC OTG TX path optimisation for 11-current Message-ID: <CAFHCsPU_n35bxx1df0MOWodFda04pPCQ1wwFCTK4zJ=Hxc%2ButA@mail.gmail.com> In-Reply-To: <55E152C4.7010209@selasky.org> References: <55A7D8CE.4020809@selasky.org> <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> <55B8F5EC.2050908@selasky.org> <46ad096c958.1a82a175@mail.schwarzes.net> <55B9C3E2.5040501@selasky.org> <46ae815c7c3.447237c8@mail.schwarzes.net> <46aece00b53.3c1cdc1f@mail.schwarzes.net> <55BB2A5F.9000502@selasky.org> <46baa16c4ce.6efd29ef@mail.schwarzes.net> <55CF31A1.5080205@selasky.org> <46ce372c895.20050775@mail.schwarzes.net> <46d0a4441bb.41f6f91d@mail.schwarzes.net> <55DD5C0A.2050401@selasky.org> <CAFHCsPVTpnd2RB4d0NvLRf9WniSkBPajJYABoPOuS4NKo%2BZ7PA@mail.gmail.com> <55E152C4.7010209@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 29, 2015 at 8:35 AM, Hans Petter Selasky <hps@selasky.org> wrote: > On 08/28/15 14:27, Svatopluk Kraus wrote: >> >> On Wed, Aug 26, 2015 at 8:26 AM, Hans Petter Selasky <hps@selasky.org> >> wrote: >>> >>> On 08/25/15 21:51, Andreas Schwarz wrote: >>>> >>>> >>>> On 24.08.15, Andreas Schwarz wrote: >>>> >>>>> With both kernels I was not able to reproduce the initial problem. >>>> >>>> >>>> >>>> By accident, today I run again into the problem (with r287086). 8( >>>> >>>> Aug 25 20:27:59 pizelot kernel: smsc0: warning: Failed to write register >>>> 0x114 >>>> Aug 25 20:45:32 pizelot kernel: smsc0: warning: Failed to read register >>>> 0x114 >>>> Aug 25 20:45:32 pizelot kernel: smsc0: warning: MII is busy >>>> Aug 25 20:46:08 pizelot kernel: smsc0: warning: Failed to write register >>>> 0x114 >>>> Aug 25 20:46:14 pizelot kernel: smsc0: warning: Failed to read register >>>> 0x114 >>>> Aug 25 20:46:14 pizelot kernel: smsc0: warning: MII is busy >>>> Aug 25 20:46:16 pizelot kernel: smsc0: warning: Failed to write register >>>> 0x114 >>>> Aug 25 20:46:46 pizelot kernel: smsc0: warning: Failed to read register >>>> 0x114 >>>> Aug 25 20:46:46 pizelot kernel: smsc0: warning: MII is busy >>>> [...] >>>> >>> >>> It might seem like some process is using all CPU on core 0, so that USB >>> doesn't get a chance to run. I would suggest maybe moving the DWC OTG >>> fast >>> IRQ handling to core #1. Is it possible you could enter kgdb, and poke >>> around which fast IRQ is doing work there? >>> >> >> Well, I finally found a courage ;) to hack dwc_otg driver to be able >> to inactivate it totally after trigger is pulled. And even then, if >> there was no interrupt and no timer on it, the problem survived. Thus, >> I thing that the driver is out of game. However, some small chance >> remains that the driver might corrupt something in kernel. But this >> indirect influence is, IMO, not likely. >> >> My subjective observation is that the slow system response can be >> caused by slow wake up from idle state. I have tried to change >> scheduler from ULE to BSD one with no MII warning and everything is >> okay result. And buildword was about one hour faster. Note that the >> trigger is very sensitive, so it can be just because system timing and >> many other things are different with different scheduler. >> >> Another obeservation is that in the bad system state, ipi rate is 10 >> times less (2 - 3 per a second) than in normal state (about 20 per a >> second) measured when system is 99% idle. >> >> Svata >> > > Hi, > > Maybe you could try to build an RPI kernel from projects/hps_head : > > https://svnweb.freebsd.org/base/projects/hps_head/ > > And test? > I disabled INVARIANTS and INVARIANT_SUPPORT options and tested it. It was not better. MII warnings were there and slow system response after buildworld finished too. The buildworld time was longer. FYI, my console is on uart. On first ssh session, "make -j6 buildworld" is run. On second ssh session, "systat -v" is run. On third ssh session, "top -P -S" is run. Usually, I do some subjective observation during first hour of buildworld. It seemed that disk was more often quite busy and consequently, cores were more often in idle state. Svata
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPU_n35bxx1df0MOWodFda04pPCQ1wwFCTK4zJ=Hxc%2ButA>