Can confirm the fix works here too. Compute jumps to 100%, but system
remains fully usable and the process moves on slowly.
Thanks again for your help, Aaron.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.l
> 100% usage of Render/3D means copy, vpp or display are stuck,
The issue is certainly related to the 100% render/compute, but this
looks like a symptom and a consequence rather than a cause.
> since multiple inputs are set, could it work when encoding a single
input each time?
Yeah, there are s
Thanks for the reply, Aaron.
The dmesg.log file is already attached above.
Your ffmpeg example is on the simple side compared to the pipeline that
creates the issue for me, where ffmpeg has multiple inputs and a
pipeline that touches both the GPU and the CPU. For simple things it
works okay here
** Description changed:
I've been using a Lenovo X12 Detachable Gen 2 model from 2024 [1] to
encode some video files with ffmpeg, and the system becomes completely
unresponsive for as long as the process executes. Although small, this
is a pretty good device hardware wise, and while execut
** Also affects: linux-signed (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux-signed (Ubuntu)
Assignee: (unassigned) => Andy Whitcroft (apw)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ub
** Attachment added: "lspci-vvnn.log"
https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+attachment/5803836/+files/lspci-vvnn.log
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-lowlatency in U
Public bug reported:
I've been using a Lenovo X12 Detachable Gen 2 model from 2024 [1] to
encode some video files with ffmpeg, and the system becomes completely
unresponsive for as long as the process executes. Although small, this
is a pretty good device hardware wise, and while executing the sys
** Attachment added: "dmesg.log"
https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+attachment/5803835/+files/dmesg.log
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-lowlatency in Ubuntu.
htt
** Attachment added: "version.log"
https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+attachment/5803834/+files/version.log
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-lowlatency in Ubuntu.
About where the notion came from, I've heard about this potential
problem pretty much since we considered using the current mount-based
model of snaps. Sounds like there's a wide belief that there is such a
limit, perhaps backed by actual reality:
http://askubuntu.com/questions/499131/how-to-use-m
Thank you very much for the test.
I heard this morning that the limit was 256 based on an error on a test
yesterday, but it must be something else then. I'll go back and ask for
more details.
** Changed in: linux (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notification b
Public bug reported:
Hello,
As discussed today in the sprint in The Hague, the number of available
loopback devices limits the number of snaps that may be installed on a
given system.
Would it be possible to increase the number of loopback devices to at
least 4096 or 8192, so that we can increas
12 matches
Mail list logo
