Date: Fri, 31 Jul 2015 17:11:39 +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: <CAFHCsPVz4cYGrZRxVz9givvct_b1CagH1W%2BbTzS1v%2Bc3sws3LQ@mail.gmail.com> In-Reply-To: <55BB6A7F.3060402@selasky.org> 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> <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> <55BB3CC6.4030002@selasky.org> <CAFHCsPXFJ_XhVsT1bRw=d20Mz=cbYdmwNNLvfs_cxJvEo8B6LA@mail.gmail.com> <55BB6A7F.3060402@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 31, 2015 at 2:30 PM, Hans Petter Selasky <hps@selasky.org> wrote: > On 07/31/15 13:55, Svatopluk Kraus wrote: >> >> On Fri, Jul 31, 2015 at 11:15 AM, Hans Petter Selasky <hps@selasky.org> >> wrote: >>> >>> Hi, >>> >>> I did some testing myself and I see the polling handler can loop many >>> times >>> when USB is active. Instead of 2 as a polling limit I've set 16. Hope >>> this >>> works too. Works fine over here. >>> >>> https://svnweb.freebsd.org/changeset/base/286118 >>> > > Hi, > >> >> Definitely, some limitation was needed there. Thanks. >> >> Unfortunatelly, it turned out that it does not help with my problem. >> It has affected system response time in good way for some time after >> the trigger is pulled. However, after 17 hours when buildworld >> finished, system response time is bad again. >> >> It also turns out that I have a problem with booting my kernels. So I >> cannot test the extra "clear RX FIFO level interrupt" patch as even >> this one line of code causes that kernel does not boot. It freezes at >> very beginning and even first printf is not printed. Thus I have to >> debug this problem firstly. It will be very funny without either jtag >> or early printf. ;) >> > > I'll possibly order an RPI2 for myself. Well, the reason why some of my kernels did not boot is that kernel start address is changing from 0x100 offset to 0x180 offset for some strange unknown reason when I change one line of code for example. If I change more lines in same file on another place, it does not happen. I will not investigate that now, but I'm able to arrange my boot script according to actual starting address. ;) Thus I was able to test both your patches and none of them makes difference. > >> Meantime, I have noticed that after reboot (system is 99% idle), I'm >> getting the following output from vmstat: >> >> > >> IMO, 24000 interrupts per a second for bcm283x_dwco is too many. > > > Yes, that's right. Note that I got about 24000 interrupts per a second during buildworld too. If I remember it correctly, it was about 4000 before r285935. When the trigger is pulled, the count is changing (in range of 4000 to 21000). It looks like something is taking more time (interrupt servicing probably). According to "systat -v", disk is going to be 100% (and more) busy very often for example. Svata > > BTW: I see you are using RPI2 while I'm using an RPI-B. That's probably why > this won't preproduce over here. > > I've made another patch to not write the GINTMSK with same values. Not sure > if it makes any difference. > > --HPS >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPVz4cYGrZRxVz9givvct_b1CagH1W%2BbTzS1v%2Bc3sws3LQ>