Bug#962003: Linux kernel 5.6: [drm:i915_gem_gtt_finish_pages [i915]] *ERROR* Failed to wait for idle; VT'd may hang
On 30.12.22 11:42, Diederik de Haas wrote: On Friday, 30 December 2022 01:48:53 CET Stefan Pietsch wrote: Affected is at least linux-image-5.6.0-1-amd64 (5.6.7-1) and linux-image-5.6.0-2-amd64 (5.6.14-1).> This also affects 5.5.0-rc5-amd64. (https://snapshot.debian.org/archive/debian/20200106T211159Z/pool/main/l/l inux/) The kernel boot option "intel_iommu=igfx_off" prevents the error message. This seems to be resolved in newer kernel versions. I'm not able to reproduce this with kernel version 5.14.0-4-amd64 (5.14.16-1). Great that it is resolved :-) As many people are affected and the Stable kernel version still seems to exhibit the problem, I want to ask a question: Are you willing to help out to narrow down as much as possible which version introduced the error and in which is was fixed? Wrt the latter, does 5.14.12-1 still show the issue? [...] Just a small update: kernel version 5.13.9-1~exp2 is also not affected by the problem.
Bug#1028463: linux: enable MEI options for Intel ARC
Control: tags -1 + patch Dear Maintainer, > In order to fully use Intel ARC GPUs, the following options need to get > enabled: > > CONFIG_INTEL_MEI_GSC > CONFIG_INTEL_MEI_PXP > CONFIG_DRM_I915_PXP > Below is the description of the features requested: # Intel MEI GSC embedded device CONFIG_INTEL_MEI_GSC=m The Intel Management Engine Interface (Intel MEI) auxiliary driver for Graphics System Controller (GSC) devices embedded in Intel graphics devices. An MEI device here called GSC can be embedded in an Intel graphics devices, to support a range of chassis tasks such as graphics card firmware update and security tasks. # Intel PXP services of ME Interface CONFIG_INTEL_MEI_PXP=m MEI Support for Protected Xe Path (PXP) Services on Intel platforms. Enables the ME FW services required for PXP support through I915 display driver of Intel. # Enable Intel PXP support CONFIG_DRM_I915_PXP=y PXP (Protected Xe Path) is an i915 component, available on graphics version 12 and newer GPUs, that helps to establish the hardware protected session and manage the status of the alive software session, as well as its life cycle. And a MR was created at: MR: https://salsa.debian.org/kernel-team/linux/-/merge_requests/633 Regards, Miguel
Processed: Re: Bug#1028463: linux: enable MEI options for Intel ARC
Processing control commands: > tags -1 + patch Bug #1028463 [src:linux] linux: enable MEI options for Intel ARC Added tag(s) patch. -- 1028463: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028463 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1028451: 2nd DisplayPort doesn't get video
On Saturday, 14 January 2023 16:30:05 CET Salvatore Bonaccorso wrote: > On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: > > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: > > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked > > > > > > upstream here: > > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171 > > > > Thanks! About an hour ago the suggested fix was to revert commit > > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 > > > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html# > > s4.2.2 describes a procedure to build a kernel with the proposed patch > > (attached). > > > > OdyX: Can you try to see whether that resolves the issue? > > Should we keep 6.1.y based kernel out of testing until this is clear? > As we aim though to have 6.1.y into bookworm I would see it as more > preferable to get 6.1.4 in for testing, we will need to followup as > well soonish with another interation for e.g. for fixing > CVE-2023-0266. As CVE-2023-0266 is fixed in 6.1.6, I'd suggest to upload that now, which I believe is ready to be uploaded already. That should keep 6.1.y out of testing for a few more days. > Now if it turns out that this is the same issue as the referenced > upstream, reverting I think we only should really revert the commit if > that's queued up for 6.1. There is currently some furhter discussion > on > https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com > /T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40 > > Given the size of the revert, there is as well a chance to re-break > other parts. So preferring to closely follow upstream here, whatever > the decision will be. Agreed. I asked 'OdyX' to test the revert to make sure it would indeed fix *this* issue, IOW what I consider standard bug triaging. But even Daniel Vetter has SERIOUS 'issues' with the revert, next to the other people who weren't happy about it. So *I* wouldn't suggest applying it to Debian (although I don't think my opinion should have much weight). As for letting this bug _continue_ to prevent a migration, ie keep the RC status, I'm against it and for downgrading it to 'important'. You could opt to add a NEWS item to warn people about this potential issue. But the original report is about the *2nd* DisplayPort being 'broken'. On zaterdag 14 januari 2023 17:04:52 CET you wrote: > Basically this issue breaks all usage of Displayport MST on amdgpu systems. > Which roughly translates to breaking external monitors for everyone using > an USB-C docks with multiple display outputs (which is pretty common these > days) on AMD laptops. As well as those like myself who daisy-chain display > port monitors with an amdgpu using graphics card. I understand that would be annoying for you, but I don't think that it would affect the majority of our users. On 2023-01-13 10:25 Daniel Vetter wrote (in that thread): > Like yes it's a regression, but apparently not a blantantly obvious one The revert may cause much wider issues which upstream may or may not care (much) about. And it would be a divergence from upstream. Getting wider testing of the 6.1 kernel is something I find much more important. There could be other issues lurking which would not get exposure and therefor wouldn't get fixed until this bug would be fixed. Uploading 6.1.6 now would give (us/)upstream a couple of more days to figure out a potential *better* way to deal with it. One which should be acceptable for the upstream Stable Kernel maintainers. But I wouldn't let this bug cause further delays to Testing. Testing is meant to test things for the next Stable release and things can and will break from time to time. If people can't deal with that, they should not be running Testing. My 0.02 signature.asc Description: This is a digitally signed message part.
Bug#1028451: 2nd DisplayPort doesn't get video
Hey, On Sat, 2023-01-14 at 16:30 +0100, Salvatore Bonaccorso wrote: > Hi, > > On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: > > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: > > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked > > > upstream here: > > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171 > > > > Thanks! About an hour ago the suggested fix was to revert commit > > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 > > > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > describes a procedure to build a kernel with the proposed patch (attached). > > > > OdyX: Can you try to see whether that resolves the issue? > > Should we keep 6.1.y based kernel out of testing until this is clear? Basically this issue breaks all usage of Displayport MST on amdgpu systems. Which roughly translates to breaking external monitors for everyone using an USB-C docks with multiple display outputs (which is pretty common these days) on AMD laptops. As well as those like myself who daisy-chain display port monitors with an amdgpu using graphics card. So I would expect this impacts a lot of people :/ Which is also why there is loads of activity and duplicates on the fd.o bug now that 6.1 is trickling into distributions. > As we aim though to have 6.1.y into bookworm I would see it as more > preferable to get 6.1.4 in for testing, we will need to followup as > well soonish with another interation for e.g. for fixing > CVE-2023-0266. > > Now if it turns out that this is the same issue as the referenced > upstream, reverting I think we only should really revert the commit if > that's queued up for 6.1. There is currently some furhter discussion > on > https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com/T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e4 > Given the size of the revert, there is as well a chance to re-break > other parts. So preferring to closely follow upstream here, whatever > the decision will be. For what it's worth; The revert as currently suggested also reverts big chunks for Intel and nvidia based GPUs, which unsurprisingly the maintainers of those aren't too thrilled about. And really i'd be amazed if it doesn't cause regressions for those systems... Unless the AMD folks pull a small/targetted fix out their hats, this is likely going to take weeks if not months before it's resolved in a way that's acceptable for 6.1.y :/ -- Sjoerd Simons
Bug#1028451: 2nd DisplayPort doesn't get video
Hi, On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked > > upstream here: > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171 > > Thanks! About an hour ago the suggested fix was to revert commit > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > describes a procedure to build a kernel with the proposed patch (attached). > > OdyX: Can you try to see whether that resolves the issue? Should we keep 6.1.y based kernel out of testing until this is clear? As we aim though to have 6.1.y into bookworm I would see it as more preferable to get 6.1.4 in for testing, we will need to followup as well soonish with another interation for e.g. for fixing CVE-2023-0266. Now if it turns out that this is the same issue as the referenced upstream, reverting I think we only should really revert the commit if that's queued up for 6.1. There is currently some furhter discussion on https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com/T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40 Given the size of the revert, there is as well a chance to re-break other parts. So preferring to closely follow upstream here, whatever the decision will be. Regards, Salvatore
Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address
Hi Jakub, On Thu, Jan 12, 2023 at 01:24:16PM +0100, Jakub Wilk wrote: > * Salvatore Bonaccorso , 2022-11-19 11:11: > > Given you were able to tackle the issue further, can you report the > > issue to upstream > > Don't count on me. Sorry! Okay thanks for beeing explicit on that. Then I guess it's on our end to try to get that upstream. Regards, Salvatore
Bug#996839: [PATCH v1] perf script flamegraph: Avoid d3-flame-graph package dependency
Hi, On Thu, Jan 12, 2023 at 02:28:59PM -0800, Ian Rogers wrote: > On Wed, Jan 11, 2023 at 10:08 AM Andreas Gerstmayr > wrote: > > > > On 11.01.23 18:13, Ian Rogers wrote: > > > On Wed, Jan 11, 2023 at 5:18 AM Andreas Gerstmayr > > > wrote: > > >> > > >> On 10.01.23 20:51, Ian Rogers wrote: > > >>> On Tue, Jan 10, 2023 at 10:02 AM Andreas Gerstmayr > > >>> wrote: > > > > On 05.01.23 10:24, Ian Rogers wrote: > > > On Wed, Jan 4, 2023 at 7:04 PM Ian Rogers wrote: > > >> > > >> Currently flame graph generation requires a d3-flame-graph template > > >> to > > >> be installed. Unfortunately this is hard to come by for things like > > >> Debian [1]. If the template isn't installed warn and download it from > > >> jsdelivr CDN. If downloading fails generate a minimal flame graph > > >> again with the javascript coming from jsdelivr CDN. > > >> > > >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839 > > >> > > >> Signed-off-by: Ian Rogers > > > > I'm not entirely convinced that this perf script should make a network > > request. In my opinion > > > > * best would be if this template gets packaged in Debian > > * alternatively print instructions how to install the template: > > > > sudo mkdir /usr/share/d3-flame-graph > > sudo wget -O /usr/share/d3-flame-graph/d3-flamegraph-base.html > > https://cdn.jsdelivr.net/npm/d3-flame-graph@4/dist/templates/d3-flamegraph-base.html > > > > * or eventually just embed the entire template (66 KB) in the Python > > file (not sure if this is permissible though, it's basically a minified > > HTML/JS blob)? > > * if the above options don't work, I'd recommend asking the user before > > making the network request, and eventually persist the template > > somewhere so it doesn't need to be downloaded every time > > > > What do you think? > > >>> > > >>> So the script following this patch is going to try 3 things: > > >>> 1) look for a local template HTML, > > >>> 2) if a local template isn't found warn and switch to downloading the > > >>> CDN version, > > >>> 3) if the CDN version fails to download then use a minimal (embedded > > >>> in the script) HTML file with JS dependencies coming from the CDN. > > >>> > > >>> For (1) there are references in the generated HTML to www.w3.org, > > >>> meaning the HTML isn't fully hermetic - although these references may > > >>> not matter. > > >> > > >> The references to w3.org are XML namespace names. As far as I'm aware > > >> they do not matter, as they are merely identifiers and are never > > >> accessed [1,2]. Therefore the generated HTML file in its current form is > > >> hermetic. > > >> > > >> This was a design decision from the start - the flame graph generation > > >> and the resulting HTML file should not use any external resources loaded > > >> over the network (the external host could be inaccessible or compromised > > >> at any time). I understand that this requirement may not apply to every > > >> user or company. > > >> > > >>> For (2) there will be a download from the CDN of the template during > > >>> the execution of flamegraph. The template is better than (3) as it > > >>> features additional buttons letting you zoom out, etc. The HTML will > > >>> contain CDN references. > > >>> For (3) the generated HTML isn't hermetic and will use the CDN. > > >>> > > >>> For (2) we could give a prompt before trying to download the template, > > >>> or we could change it so that we give the wget command. I wouldn't > > >>> have the wget command require root privileges, I'd say that the > > >>> template could be downloaded and then the path of the download given > > >>> as an option to the flamegraph program. Downloading the file and then > > >>> adding an option to flamegraph seems inconvenient to the user, > > >>> something that the use of urllib in the patch avoids - it is > > >>> essentially just doing this for the user without storing the file on > > >>> disk. I think I prefer to be less inconvenient, and so the state of > > >>> the code at the moment looks best to me. Given that no choice results > > >>> in a fully hermetic HTML file, they seem similar in this regard. Is it > > >>> okay to try a download with urllib? Should there be a prompt? I think > > >>> the warning is enough and allows scripts, etc. using flamegraph to > > >>> more easily function across differing distributions. > > >> > > >> I fully agree, your changes make the flame graph generation more > > >> convenient in case the template is not installed. Also, downloading the > > >> template to a local directory and having to specify the path to the > > >> template every time is an inconvenience. > > >> > > >> I think it is a tradeoff between convenience and security/privacy. > > >> jsdelivr can get compromised, serving malicious JS (well, in that case, > > >> printing instructions to jsdeli
