Re: [Regression] 6.9.0: WARNING: workqueue: WQ_MEM_RECLAIM ttm:ttm_bo_delayed_delete [ttm] is flushing !WQ_MEM_RECLAIM events:qxl_gc_work [qxl]
On Wed, May 08, 2024 at 02:51:10PM +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 08.05.24 14:35, Anders Blomdell wrote:
> > On 2024-05-07 07:04, Linux regression tracking (Thorsten Leemhuis) wrote:
> >> On 06.05.24 16:30, David Wang wrote:
> On 30.04.24 08:13, David Wang wrote:
> >>
> And confirmed that the warning is caused by
> 07ed11afb68d94eadd4ffc082b97c2331307c5ea and reverting it can fix.
> >>>
> >>> The kernel warning still shows up in 6.9.0-rc7.
> >>> (I think 4 high load processes on a 2-Core VM could easily trigger
> >>> the kernel warning.)
> >>
> >> Thx for the report. Linus just reverted the commit 07ed11afb68 you
> >> mentioned in your initial mail (I put that quote in again, see above):
> >>
> >> 3628e0383dd349 ("Reapply "drm/qxl: simplify qxl_fence_wait"")
> >> https://git.kernel.org/torvalds/c/3628e0383dd349f02f882e612ab6184e4bb3dc10
> >>
> >> So this hopefully should be history now.
> >>
> > Since this affects the 6.8 series (6.8.7 and onwards), I made a CC to
> > sta...@vger.kernel.org
>
> Ohh, good idea, I thought Linus had added a stable tag, but that is not
> the case. Adding Greg as well and making things explicit:
>
> @Greg: you might want to add 3628e0383dd349 ("Reapply "drm/qxl: simplify
> qxl_fence_wait"") to all branches that received 07ed11afb68d94 ("Revert
> "drm/qxl: simplify qxl_fence_wait"") (which afaics went into v6.8.7,
> v6.6.28, v6.1.87, and v5.15.156).
Now queued up, thanks.
greg k-h
Re: [PATCH v2 1/1] Revert "drm/qxl: simplify qxl_fence_wait"
On Thu, Apr 04, 2024 at 07:14:48PM +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").
>
> Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
> Link: https://lore.kernel.org/regressions/ztgydqrlk6wx_...@eldamar.lan/
> 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 | 50 +++
> include/linux/dma-fence.h | 7 +
> 2 files changed, 52 insertions(+), 5 deletions(-)
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You have marked a patch with a "Fixes:" tag for a commit that is in an
older released kernel, yet you do not have a cc: stable line in the
signed-off-by area at all, which means that the patch will not be
applied to any older kernel releases. To properly fix this, please
follow the documented rules in the
Documentation/process/stable-kernel-rules.rst file for how to resolve
this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
On Wed, Jul 22, 2015 at 09:03:53AM -0500, Jeremy White wrote: On 07/09/2015 05:06 AM, Alex Elsayed wrote: Alan Stern wrote: On Mon, 6 Jul 2015, Jeremy White wrote: Anything else fundamental to usbip that should inform the design of a usbredir driver? usbip appears to be based off a 2004 vintage of dummy_hcd. I'll look thoughtfully at the current dummy_hcd; please let me know if there is anything else I should consider. One thing that springs to mind is USB-3 streams. When dummy-hcd was expanded to include USB-3, that was the major new ingredient. Another thing that comes to mind is that the USB-IF has its own official standard for this kind of thing now, called Media-Agnostic USB[1]. In November of 2014 a driver[2] was posted, followed by a second version[3], and it is apparently being refined inside Intel[4]. [1] http://www.usb.org/developers/docs/devclass_docs/Media_Agnostic_USB_v1.0.zip [2] http://thread.gmane.org/gmane.linux.kernel/1820297 [3] http://thread.gmane.org/gmane.linux.drivers.driver-project.devel/60498 [4] http://article.gmane.org/gmane.linux.drivers.driver-project.devel/60757 Thanks for the pointer, Alex. I spent some time with the spec and their proposed code. It does seem plausible that XSpice could use a mausb/usbredir protocol converter. So if there was a mausb kernel module, I could potentially implement support in XSpice in user space and not need a usbredir module. I sent an email to the two developers at Intel to ask if there had been any further progress and if I could collaborate with them. I have not heard back. The MA spec is substantial and seems well thought out. But the usbredir protocol has the virtue of being relatively mature - it's 5 years old, with code in daily use. At this point it seems the best path forward is to continue work on the usbredir kernel module, which I will do unless I get some new information. Please work with the existing people, or with the existing spec, I don't want to be adding multiple versions of this type of protocol to the kernel. As it is, I really don't even want to take your code, given that usbip is already there. Ignoring it isn't ok. thanks, greg k-h ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
On Wed, Jul 01, 2015 at 10:55:49AM -0500, Jeremy White wrote: On 07/01/2015 12:44 AM, Greg KH wrote: On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote: 1. Is the basic premise reasonable? Is Hans correct in asserting that an alternate USB over IP module will be considered? I have no idea, if it fully replaces the usbip functionality, I don't see why that would be rejected. But why can't you just fix up usbip for the issues you find lacking? This is what Hans said 5 years ago: [1] 3) The protocol itself is far from ideal. Number 3 is the big deal breaker for me. I've looked at the (undocumented) protocol by sifting through the source. And it is very low level, all it does is shove usb packets back and forth over the network. It has no concept of configuration setting (the docs say make sure the device is in the right configuration before sharing it). No concept of caching things like descriptors, active configuration, per interface alt setting, etc. Besides missing a lot of useful smarts the whole one packet at a time approach does not really fly when it comes to isoc endpoints. As there paper states, the vm-host / guest os drivers need to make sure enough packets are submitted / queued at all time to gap the network delay / fill the network pipe. For iso endpoints it makes much more sense to have a start / stop stream model, where the usb-host pumpes the urb ringbuffer and sends out data received from the usb device to the vm-host (isoc input endp case), or sends data received from the vm-host (through a buffer to deal with network jitter) to the isoc output endpoint. This also halves the number of packets which need to be send over the network, as their is no need for the vm-host to send a request for each packet once an input stream has started / for the usb-host to send an ack for each delivered packet for an ouput stream. It would still send an error when an error occurs, but their is no reason to ack all delivered packets. Given the delay caused by buffering, etc. not being able to match up the error to an exact packet is not important, as from the vm-host emulated usb hc (host controller), the packet has long been delivered already. Instead we will simply report the error to the guest os for the next packet enqueued by the guest after receiving notification of the error from the usb-host. The protocol is now documented, so that part is out of date. I don't see any evidence that the bulk of his other concerns have been addressed, however. Because no one has cared to. Now it seems you care, so I'd prefer to see someone fix this up instead of adding another protocol that does much the same thing. 2. Do I correctly understand that there are no circumstances where copied code can be left unmodified? Even in the case where the copied code is working, production code, and the changes would be just for style? I doubt the changes would just be for style if you are craming it into the kernel tree, as it's a totally different environment from any other place this code might have been running in before. Well, the checkpatch.pl reports were all style (and mostly whitespace); roughly 3000 of them against 3000 lines of code :-/. I did review the code, looking for areas where I thought it would badly cram into the kernel, and I adjusted the few I found (and sent changes upstream). style matters, as it's a thing with your brain. You learn patterns and if the patterns change, you have to do more work and don't see the real issues involved. So by ignoring our style you are saying you don't want anyone else in the kernel community to ever review or work on the code, which isn't ok. Please do the most basic of polite things and fix this up before posting things. It is often difficult for a newcomer to know what the polite thing is, even after studying FAQs and documentation. Did you read Documentation/SubmittingPatches? Yes, and SubmittingDrivers, SubmitChecklist, every link listed on #kernelnewbies, and the entire lkml FAQ as well. In hindsight, I think it's mostly a failure of common sense on my part. The one constructive suggestion I would offer is that the 'RFC PATCH' is used heavily by the linux kernel community, but I didn't find much discussion of it in the documentation or FAQs. I think I jumped to some erroneous conclusions about it's use. I'm willing to try to add a note on that, if that would be helpful. I personally ignore RFC patches unless they are tiny and in an area that I happened to be worried about / working on at the moment as it feels that the submitter doesn't think they are good enough to be merged as-is, so I'll wait until they feel it is worthy for submission to review it. thanks, greg k-h ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http
Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
On Tue, Jun 30, 2015 at 04:44:10PM -0500, Jeremy White wrote: This module uses the usbredir protocol and user space tools, which are used by the SPICE project. Signed-off-by: Jeremy White jwh...@codeweavers.com --- MAINTAINERS |6 + drivers/usb/Kconfig |2 + drivers/usb/Makefile|1 + drivers/usb/usbredir/Kconfig| 25 + drivers/usb/usbredir/Makefile |4 + drivers/usb/usbredir/README | 20 + drivers/usb/usbredir/TODO | 12 + drivers/usb/usbredir/device.c | 327 + drivers/usb/usbredir/hub.c | 489 drivers/usb/usbredir/main.c | 100 ++ drivers/usb/usbredir/redir.c| 535 drivers/usb/usbredir/rx.c | 40 + drivers/usb/usbredir/strtok_r.c | 69 + drivers/usb/usbredir/strtok_r.h | 26 + drivers/usb/usbredir/sysfs.c| 145 +++ drivers/usb/usbredir/tx.c | 151 +++ drivers/usb/usbredir/urb.c | 266 drivers/usb/usbredir/usbredir.h | 225 drivers/usb/usbredir/usbredirfilter.c | 294 + drivers/usb/usbredir/usbredirfilter.h | 144 +++ drivers/usb/usbredir/usbredirparser.c | 1795 +++ drivers/usb/usbredir/usbredirparser.h | 386 ++ drivers/usb/usbredir/usbredirproto-compat.h | 88 ++ drivers/usb/usbredir/usbredirproto.h| 309 + 24 files changed, 5459 insertions(+) create mode 100644 drivers/usb/usbredir/Kconfig create mode 100644 drivers/usb/usbredir/Makefile create mode 100644 drivers/usb/usbredir/README create mode 100644 drivers/usb/usbredir/TODO create mode 100644 drivers/usb/usbredir/device.c create mode 100644 drivers/usb/usbredir/hub.c create mode 100644 drivers/usb/usbredir/main.c create mode 100644 drivers/usb/usbredir/redir.c create mode 100644 drivers/usb/usbredir/rx.c create mode 100644 drivers/usb/usbredir/strtok_r.c create mode 100644 drivers/usb/usbredir/strtok_r.h create mode 100644 drivers/usb/usbredir/sysfs.c create mode 100644 drivers/usb/usbredir/tx.c create mode 100644 drivers/usb/usbredir/urb.c create mode 100644 drivers/usb/usbredir/usbredir.h create mode 100644 drivers/usb/usbredir/usbredirfilter.c create mode 100644 drivers/usb/usbredir/usbredirfilter.h create mode 100644 drivers/usb/usbredir/usbredirparser.c create mode 100644 drivers/usb/usbredir/usbredirparser.h create mode 100644 drivers/usb/usbredir/usbredirproto-compat.h create mode 100644 drivers/usb/usbredir/usbredirproto.h It's pointless to post a patch that you know has problems with it (i.e. it's not even in proper kernel coding style), as it will never be reviewed or even looked at. Please do the most basic of polite things and fix this up before posting things. And really, all in one patch? That too is pretty hard to review... thanks, greg k-h ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote: It's pointless to post a patch that you know has problems with it (i.e. it's not even in proper kernel coding style), as it will never be reviewed or even looked at. Thanks for the reply, and I'm sorry for the clumsy ask. I would still appreciate feedback on two points: 1. Is the basic premise reasonable? Is Hans correct in asserting that an alternate USB over IP module will be considered? I have no idea, if it fully replaces the usbip functionality, I don't see why that would be rejected. But why can't you just fix up usbip for the issues you find lacking? 2. Do I correctly understand that there are no circumstances where copied code can be left unmodified? Even in the case where the copied code is working, production code, and the changes would be just for style? I doubt the changes would just be for style if you are craming it into the kernel tree, as it's a totally different environment from any other place this code might have been running in before. Please do the most basic of polite things and fix this up before posting things. It is often difficult for a newcomer to know what the polite thing is, even after studying FAQs and documentation. Did you read Documentation/SubmittingPatches? I appreciate your patience (and clue bats) as I try to learn. And really, all in one patch? That too is pretty hard to review... Yeah. I see the point of pain. I did not see a solution as I formed the patch, but I'll try harder before resending. Remember you need to make this trivial to review in order to get it accepted. You have to do extra work because of this because our limited resource is reviewers and maintainers, not developers. thanks, greg k-h ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
