DWC OTG TX path optimisation for 11-current

[Hans Petter Selasky]

On 08/28/15 14:27, Svatopluk Kraus wrote:
> On Wed, Aug 26, 2015 at 8:26 AM, Hans Petter Selasky <hps at 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?

--HPS