Date: Thu, 30 Jul 2015 17:22:55 +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: [RPI-B] [HEADS UP] DWC OTG TX path optimisation for 11-current Message-ID: <CAFHCsPXmm8rhZpiQ4uhPCkwBKC1o5gMLFYHEj9s5e3ObU21BPg@mail.gmail.com> In-Reply-To: <55BA1AC7.4050602@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> <CAFHCsPXmQCKt-5xWa6XwECqFO5oz4mT9m1mPu0dKmmQ%2BG9yUAA@mail.gmail.com> <55B9F914.7030403@selasky.org> <CAFHCsPVzFE-a2x2rsZRshGZExwZX9dCz2hXtpb2t5LFKN-14aQ@mail.gmail.com> <55BA1889.4040509@selasky.org> <55BA1AC7.4050602@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--047d7bd75cb016f6d1051c19479b Content-Type: text/plain; charset=UTF-8 Well, I'm trying to join answers for your previous emails in this one. On Thu, Jul 30, 2015 at 2:38 PM, Hans Petter Selasky <hps@selasky.org> wrote: > On 07/30/15 14:28, Hans Petter Selasky wrote: > > Can you run only "usbdump" while the interface is UP and the errors are printed in the console? > > We are looking for ERR different from "0". It looks that there is no ERR different from "0" in usbdump at all. Again, it looks that the load is generated "internally" and it does not depend on explicit usb request directly. > > Does the interface come back when you down/up it? Yes, it works. > BTW: All your USB HUBs are self powered? Yes, my usb hub has external power supply (12V, 4A) and my usb disk is connected only. > > Does the device recover if you do: > > usbconfig -d X.Y reset > > for the ue0 ? Yes, it does. Anyhow, I think that I figured out why the system has so slow response time when it's triggered. In general, it's not good idea to not limit somehow interrupt filter execution time. If something wrong is happening, then such filter can halt all system. I can get back fast system response time with attached patch. Note that it's only a proof-of-concept patch and it does not remove the problem. There is still something what generates big load when it's triggered even if system is 99% idle after trigger was pulled. Svata --047d7bd75cb016f6d1051c19479b Content-Type: text/plain; charset=US-ASCII; name="dwc_otg.c.diff" Content-Disposition: attachment; filename="dwc_otg.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_icqcgvjd0 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZHdjX290Zy5jIGIvc3lzL2Rldi91 c2IvY29udHJvbGxlci9kd2Nfb3RnLmMKaW5kZXggNTFmMDgzYi4uY2RlMzY2ZiAxMDA2NDQKLS0t IGEvc3lzL2Rldi91c2IvY29udHJvbGxlci9kd2Nfb3RnLmMKKysrIGIvc3lzL2Rldi91c2IvY29u dHJvbGxlci9kd2Nfb3RnLmMKQEAgLTI1NTQsOCArMjU1NCwxMiBAQCBkd2Nfb3RnX2ludGVycnVw dF9wb2xsX2xvY2tlZChzdHJ1Y3QgZHdjX290Z19zb2Z0YyAqc2MpCiAJdWludDMyX3QgdGVtcDsK IAl1aW50OF90IGdvdF9yeF9zdGF0dXM7CiAJdWludDhfdCB4OworCXVpbnQzMl90IGNvdW50ID0g MDsKIAogcmVwZWF0OgorCWlmIChjb3VudCsrID4gMikKKwkJcmV0dXJuOworCiAJLyogZ2V0IGFs bCBjaGFubmVsIGludGVycnVwdHMgKi8KIAlmb3IgKHggPSAwOyB4ICE9IHNjLT5zY19ob3N0X2No X21heDsgeCsrKSB7CiAJCXRlbXAgPSBEV0NfT1RHX1JFQURfNChzYywgRE9UR19IQ0lOVCh4KSk7 Cg== --047d7bd75cb016f6d1051c19479b--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPXmm8rhZpiQ4uhPCkwBKC1o5gMLFYHEj9s5e3ObU21BPg>