Hi all,
As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.
Please fix it up to NOT have duplicates in multiple branches that end up in Linus's tree at different times. Or if you MUST do that, then give us a chance to figure out that it IS a duplicate. As-is, it's not working at all, and I think I need to just drop all patches for this driver that are tagged for stable going forward and rely on you all to provide a proper set of backported fixes when you say they are needed.
Again, what you are doing today is NOT ok and is broken. Please fix.
greg k-h
On 2024-08-12 11:00, Greg KH wrote:
Hi all,
As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.
Hi Greg,
I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:
------------------ original commit in Linus's tree ------------------ From 24e82654e98e96cece5d8b919c522054456eeec6 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexander.deucher@amd.comDate: Sun, 14 Apr 2024 13:06:39 -0400 Subject: [PATCH] drm/amdkfd: don't allow mapping the MMIO HDP page with large pages ...
On 6.1 and 6.6, the patch was already applied by you in May:
$ git log --pretty=fuller stable/linux-6.6.y --grep "drm/amdkfd: don't allow mapping the MMIO HDP page with large pages" commit 4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724 Author: Alex Deucher alexander.deucher@amd.com AuthorDate: Sun Apr 14 13:06:39 2024 -0400 Commit: Greg Kroah-Hartman gregkh@linuxfoundation.org CommitDate: Fri May 17 12:02:34 2024 +0200
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages ...
On 6.10 it was already upstream.
On 5.4-5.15 it doesn't apply because of conflicts. I can resolve those and send the fixed patches out for you.
Regards, Felix
Please fix it up to NOT have duplicates in multiple branches that end up in Linus's tree at different times. Or if you MUST do that, then give us a chance to figure out that it IS a duplicate. As-is, it's not working at all, and I think I need to just drop all patches for this driver that are tagged for stable going forward and rely on you all to provide a proper set of backported fixes when you say they are needed.
Again, what you are doing today is NOT ok and is broken. Please fix.
greg k-h
On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling felix.kuehling@amd.com wrote:
On 2024-08-12 11:00, Greg KH wrote:
Hi all,
As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.
Hi Greg,
I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:
I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.
Alex
------------------ original commit in Linus's tree ------------------ From 24e82654e98e96cece5d8b919c522054456eeec6 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@amd.com>Date: Sun, 14 Apr 2024 13:06:39 -0400 Subject: [PATCH] drm/amdkfd: don't allow mapping the MMIO HDP page with large pages ...On 6.1 and 6.6, the patch was already applied by you in May:
$ git log --pretty=fuller stable/linux-6.6.y --grep "drm/amdkfd: don't allow mapping the MMIO HDP page with large pages" commit 4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724 Author: Alex Deucher <alexander.deucher@amd.com> AuthorDate: Sun Apr 14 13:06:39 2024 -0400 Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CommitDate: Fri May 17 12:02:34 2024 +0200 drm/amdkfd: don't allow mapping the MMIO HDP page with large pages ...On 6.10 it was already upstream.
On 5.4-5.15 it doesn't apply because of conflicts. I can resolve those and send the fixed patches out for you.
Regards, Felix
Please fix it up to NOT have duplicates in multiple branches that end up in Linus's tree at different times. Or if you MUST do that, then give us a chance to figure out that it IS a duplicate. As-is, it's not working at all, and I think I need to just drop all patches for this driver that are tagged for stable going forward and rely on you all to provide a proper set of backported fixes when you say they are needed.
Again, what you are doing today is NOT ok and is broken. Please fix.
greg k-h
On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling felix.kuehling@amd.com wrote:
On 2024-08-12 11:00, Greg KH wrote:
Hi all,
As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.
Hi Greg,
I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:
I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.
Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.
If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.
thanks,
greg k-h
On Thu, Aug 15, 2024 at 1:11 AM Greg KH gregkh@linuxfoundation.org wrote:
On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling felix.kuehling@amd.com wrote:
On 2024-08-12 11:00, Greg KH wrote:
Hi all,
As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.
Hi Greg,
I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:
I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.
Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.
If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.
Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.
Thanks,
Alex
thanks,
greg k-h
On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
On Thu, Aug 15, 2024 at 1:11 AM Greg KH gregkh@linuxfoundation.org wrote:
On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling felix.kuehling@amd.com wrote:
On 2024-08-12 11:00, Greg KH wrote:
Hi all,
As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.
Hi Greg,
I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:
I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.
Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.
If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.
Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.
Can you give me a list of the git ids that I should be ignoring for 6.12-rc1? Otherwise again, it's a huge waste of time on my side trying to sift through them and figure out if the rejection is real or not...
thanks,
greg k-h
On Sat, Aug 24, 2024 at 1:23 AM Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
On Thu, Aug 15, 2024 at 1:11 AM Greg KH gregkh@linuxfoundation.org wrote:
On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling felix.kuehling@amd.com wrote:
On 2024-08-12 11:00, Greg KH wrote:
Hi all,
As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.
Hi Greg,
I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:
I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.
Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.
If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.
Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.
Can you give me a list of the git ids that I should be ignoring for 6.12-rc1? Otherwise again, it's a huge waste of time on my side trying to sift through them and figure out if the rejection is real or not...
8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2 295d91cbc700 drm/amd/display: Check for NULL pointer 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes
Thanks.
Alex
thanks,
greg k-h
On Tue, Aug 27, 2024 at 10:18:27AM -0400, Alex Deucher wrote:
On Sat, Aug 24, 2024 at 1:23 AM Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
On Thu, Aug 15, 2024 at 1:11 AM Greg KH gregkh@linuxfoundation.org wrote:
On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling felix.kuehling@amd.com wrote:
On 2024-08-12 11:00, Greg KH wrote: > Hi all, > > As some of you have noticed, there's a TON of failure messages being > sent out for AMD gpu driver commits that are tagged for stable > backports. In short, you all are doing something really wrong with how > you are tagging these. Hi Greg,
I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:
I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.
Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.
If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.
Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.
Can you give me a list of the git ids that I should be ignoring for 6.12-rc1? Otherwise again, it's a huge waste of time on my side trying to sift through them and figure out if the rejection is real or not...
8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2 295d91cbc700 drm/amd/display: Check for NULL pointer 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes
Please resend this after -rc1 is out, so we don't have to hunt for it again.
thanks,
greg k-h
Resending now that rc1 is out. These should be ignored for stable.
8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2 295d91cbc700 drm/amd/display: Check for NULL pointer 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes
Alex
On Wed, Sep 4, 2024 at 1:23 PM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Aug 27, 2024 at 10:18:27AM -0400, Alex Deucher wrote:
On Sat, Aug 24, 2024 at 1:23 AM Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
On Thu, Aug 15, 2024 at 1:11 AM Greg KH gregkh@linuxfoundation.org wrote:
On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling felix.kuehling@amd.com wrote: > > On 2024-08-12 11:00, Greg KH wrote: > > Hi all, > > > > As some of you have noticed, there's a TON of failure messages being > > sent out for AMD gpu driver commits that are tagged for stable > > backports. In short, you all are doing something really wrong with how > > you are tagging these. > Hi Greg, > > I got notifications about one KFD patch failing to apply on six branches > (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you > already applied this patch on two branches back in May. The emails had a > suspicious looking date in the header (Sep 17, 2001). I wonder if there > was some date glitch that caused a whole bunch of patches to be re-sent > to stable somehow:
I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.
Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.
If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.
Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.
Can you give me a list of the git ids that I should be ignoring for 6.12-rc1? Otherwise again, it's a huge waste of time on my side trying to sift through them and figure out if the rejection is real or not...
8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2 295d91cbc700 drm/amd/display: Check for NULL pointer 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes
Please resend this after -rc1 is out, so we don't have to hunt for it again.
thanks,
greg k-h
On Mon, Sep 30, 2024 at 10:10:25AM -0400, Alex Deucher wrote:
Resending now that rc1 is out. These should be ignored for stable.
8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2 295d91cbc700 drm/amd/display: Check for NULL pointer 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes
Thanks, that helped a lot.
However the following two commits did not apply, is that because they are already in the tree or do they need someone to properly backport them?
c2ed7002c061 ("drm/amd/display: Use SDR white level to calculate matrix coefficients") b74571a83fd3 ("drm/amd/display: Use full update for swizzle mode change")
thanks,
greg k-h
On Tue, Oct 1, 2024 at 6:04 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Sep 30, 2024 at 10:10:25AM -0400, Alex Deucher wrote:
Resending now that rc1 is out. These should be ignored for stable.
8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2 295d91cbc700 drm/amd/display: Check for NULL pointer 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes
Thanks, that helped a lot.
However the following two commits did not apply, is that because they are already in the tree or do they need someone to properly backport them?
c2ed7002c061 ("drm/amd/display: Use SDR white level to calculate matrix coefficients") b74571a83fd3 ("drm/amd/display: Use full update for swizzle mode change")
Looks like they will need backports.
Alex
thanks,
greg k-h
On Wed, Aug 14, 2024 at 04:39:29PM -0400, Felix Kuehling wrote:
On 2024-08-12 11:00, Greg KH wrote:
Hi all,
As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.
Hi Greg,
I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:
------------------ original commit in Linus's tree ------------------ From 24e82654e98e96cece5d8b919c522054456eeec6 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexander.deucher@amd.comDate: Sun, 14 Apr 2024 13:06:39 -0400
That's the real date, ignore the 2001 thing, that's from git.
Subject: [PATCH] drm/amdkfd: don't allow mapping the MMIO HDP page with large pages ...
On 6.1 and 6.6, the patch was already applied by you in May:
$ git log --pretty=fuller stable/linux-6.6.y --grep "drm/amdkfd: don't allow mapping the MMIO HDP page with large pages" commit 4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724 Author: Alex Deucher alexander.deucher@amd.com AuthorDate: Sun Apr 14 13:06:39 2024 -0400 Commit: Greg Kroah-Hartman gregkh@linuxfoundation.org CommitDate: Fri May 17 12:02:34 2024 +0200
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages...
On 6.10 it was already upstream.
Then why did we have it in the tree again with different commit ids? That's the issue here, and the major confusion as there is no way for us to determine if this is a commit that has been in the tree already or if it's just a normal failure.
On 5.4-5.15 it doesn't apply because of conflicts. I can resolve those and send the fixed patches out for you.
If it is needed in those branches, please do so.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Alex Deucher -
Felix Kuehling -
Greg KH