Bug#1054514: (subset) [PATCH v2 1/1] Revert "drm/qxl: simplify qxl_fence_wait"
On Thu, 04 Apr 2024 19:14:48 +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
>
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
> Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
> by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").
>
> [...]
Applied to misc/kernel.git (drm-misc-fixes).
Thanks!
Maxime
Bug#1054514: [PATCH 1/1] drm/qxl: fixes qxl_fence_wait
Hi,
On Wed, Mar 20, 2024 at 04:25:48PM +0100, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 08.03.24 02:08, Alex Constantino wrote:
> > Fix OOM scenario by doing multiple notifications to the OOM handler through
> > a busy wait logic.
> > Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> > result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> > timeout.
> >
> > Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
> > Link:
> > https://lore.kernel.org/regressions/fb0fda6a-3750-4e1b-893f-97a3e402b...@leemhuis.info
> > Reported-by: Timo Lindfors
> > Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
> > Signed-off-by: Alex Constantino
> > ---
> > drivers/gpu/drm/qxl/qxl_release.c | 20 ++--
> > 1 file changed, 14 insertions(+), 6 deletions(-)
>
> Hey Dave and Gerd as well as Thomas, Maarten and Maxime (the latter two
> I just added to the CC), it seems to me this regression fix did not
> maybe any progress since it was posted. Did I miss something, is it just
> "we are busy with the merge window", or is there some other a reason?
> Just wondering, I just saw someone on a Fedora IRC channel complaining
> about the regression, that's why I'm asking. Would be really good to
> finally get this resolved...
I've ping'd Gerd last week about it, but he couldn't remember the
details of why that patch was warranted in the first place.
If it works, I'd prefer to revert the original patch that we know used
to work instead of coming up with some less proven logic, which seems to
be quite different to what it used to be.
Alex, could you try reverting 5a838e5d5825c85556011478abde708251cc0776
and letting us know the result?
Thanks!
Maxime
signature.asc
Description: PGP signature
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 03:23:33PM +0200, Hans de Goede wrote: Hi, On 24-07-15 15:16, Maxime Ripard wrote: On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote: There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) While I agree with you on the fact that more board needs to have the regulators enabled, I really don't think that making some newbies doing it without any schematics (and boards I guess?) They will only be writing patches for boards which I have, and the patches will be tested on the actual boards before submitting them upstream. I will be collecting and double checking all patches before sending them to you. I will let you know if they blow up any boards :) But I do not really expect that to happen. is a good thing when it comes to something that can permanently damage a board. I'd expect that such changes would be carefully done and tested before being submitted. And they will be, see above. Perfect then :) My point was simply that we shouldn't have automated changes for this, just for the sake of having regulators for all the boards. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Bug#793185: [linux-sunxi] forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 08:34:34AM +0200, Leonardo Canducci wrote: Attaching kernel config files from /boot (3.16, 4.0 and 4.1 from stable, unstable and experimental). We're using the cpufreq-dt driver, that is compiled as a module. Is the module loaded? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Bug#793185: [linux-sunxi] forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Hi, On Thu, Jul 23, 2015 at 12:58:09PM -0700, leonardo.candu...@gmail.com wrote: Hi there! I've just installed Debian stable on my Cubieboard using their installer. Debian's mainline 3.16 kernel works fine but cpufreq is missing (sunxi 3.4 kernel supports it). I've submitted a bug [0] in the Debian BTS and tried kernel 4.0 and 4.1 from unstable and experimental branches with no success (cpufreq support should be there from linux 4.0 [1]). I'm forwarding that bug here as suggested. There's already a bunch of infos in there, but the whole kernel configuration seems to be missing, could you provide it please? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote: There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) While I agree with you on the fact that more board needs to have the regulators enabled, I really don't think that making some newbies doing it without any schematics (and boards I guess?) is a good thing when it comes to something that can permanently damage a board. I'd expect that such changes would be carefully done and tested before being submitted. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 05:58:34AM -0700, m.silentcr...@gmail.com wrote: So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support to the cubietruck, shouldn't adding these lines to the device trees of the other 5 A20 devices enable CPU voltage scaling there? Basically yes. The point that Chen-Yu made is that he and other developers don't have all boards available to verify that all of these boards use the same layout for their wiring. The hard part is that there's not a single reference design there. There's some pattern, but it's not at all something that can be made generic, because to a few exceptions, no one uses the same regulator to power the same thing, and with the same constraints (that directly depend on the stuff that you have connected on the other end of the regulator). So any mechanical change is not something that can be done. Especially for something that might blow up your board. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 05:49:42AM -0700, Thomas Kaiser wrote: Hi, Timo wrote: I think what Maxime was trying to say is, that while all of your boards support Cpufreq, only the Cubietruck supports voltage scaling because only Cubietruck has the power regulator nodes defined in it's dts file (just have a look at the last lines of the Cubitruck dts file and compare that to the dts file, let's say, for Bananapi). On the other boards, the frequency is scaled, but the voltage always stays at 1.4V as set in U-Boot (that means the voltages in the cpufreq operating points are not used on these boards). At least that's what I understand after a recent email axchange with Chen-Yu Tsai. Ah, now I think I understand. You're talking about these lines here? https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269 So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support to the cubietruck, shouldn't adding these lines to the device trees of the other 5 A20 devices enable CPU voltage scaling there? That and https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L108-L110 Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 04:36:57AM -0700, Thomas Kaiser wrote: Hi, Hans de Goede wrote: Is the debian kernel building the axp209 mfd driver, and also the axp20x regulator drive, and do these get loaded properly on the cubietruck ? Unfortunately I've no idea since i fetch the kernel sources directly from git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git And this was the kernel config I used: https://github.com/igorpecovnik/lib/blob/429867a80c85011b6d31048481c0beb1c7bc76fa/config/linux-sunxi-next.config # CONFIG_REGULATOR_AXP20X is not set What puzzles me is that exactly the same kernel (I used Igor Pečovnik's build system) provides working cpufreq support on 5 A20 devices and one it fails. And none of those 5 use CPU voltage scaling. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 05:12:57AM -0700, Thomas Kaiser wrote: What puzzles me is that exactly the same kernel (I used Igor Pečovnik's build system) provides working cpufreq support on 5 A20 devices and one it fails. And none of those 5 use CPU voltage scaling. Maybe I don't understand the whole meaning. But on a Banana Pi a few weeks ago [1] and on a pcDuino3 Nano I used the last days for USB/UAS benchmarks the cpufreq stuff was available below /sys/devices/system/cpu/cpu0/cpufreq/ and altering parameters always had an effect. Yes, and it had an effect on the frequency, not the voltage. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
