https://bugzilla.suse.com/show_bug.cgi?id=1225296 https://bugzilla.suse.com/show_bug.cgi?id=1225296#c39 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(tiwai@suse.com) --- Comment #39 from Felix Miata <mrmazda@earthlink.net> --- (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? -- You are receiving this mail because: You are on the CC list for the bug.