Comment # 39 on bug 1225296 from Felix Miata

(In reply to Takashi Iwai from comment #38)
> If the problem is seen in the upstream, it must be fixed there. 

I thought I already made it clear enough I knew that, since Debian, Fedora &
Ubuntu kernels produce same bad behavior.

> For that,
> you'd need to report to the upstream, and it'd help to tell the *upstream*
> regression range, not Leap 15.6. 

I'm aware of that too, and was hoping the date range/kernel range (merely 2) of
the backports to the only two Leap kernels that could include the offender
could be leveraged somehow, saving somebody a lot of bisect effort. An answer
to this is the only thing that has prevented me from already reporting
upstream.

> Of course, if you can try to bisect Leap
> kernel and identify the commit by yourself, it'd be helpful, too.

I would think someone familiar with detailed bisection could make short work of
it given the 2 kernel range already established. That someone is not me.

Procedurally, what are typical time intervals between upstream commits, and
backporting them to SLE-SP/Leap kernels? How many commits might there be in
that 25 day, 2 Leap 6.4 kernels period?