Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 23.05.2017 um 12:14 schrieb Lukas Wunner:
On Tue, May 23, 2017 at 09:32:38AM +0200, Christian König wrote:
Am 23.05.2017 um 05:55 schrieb Michel Dänzer:
On 23/05/17 12:50 PM, Lukas Wunner wrote:
On Tue, May 23, 2017 at 12:09:49PM +0900, Michel Dänzer wrote:
On 22/05/17 11:04 PM, Lukas Wunner wrote:
On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote:
On Thu, May 18 2017, Lukas Wunner wrote:
[snip]
Reported-by: Nicolai Stange <nicstange@xxxxxxxxx>
Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo")
Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx>
---

Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
needs to be fixed, so sending out with a proper commit message now.
The bug was only introduced to radeon, not amdgpu.
Tested-by: Nicolai Stange <nicstange@xxxxxxxxx>

Thanks for the quick fix!

@Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
land before -rc3 because Sean Paul has already sent out the -rc2 pull.
I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
take it yourself?  Whichever you prefer.  Thanks & sorry for the breakage!
I've learned this morning that Alex is on vacation.
Christian König is standing in for Alex.
By his own account, he already has "all hands full replacing him [Alex]",
explicitly asked Daniel to merge an amdgpu patch through drm-misc-next for
this reason and lacks permission to update branches in Alex' repo on fdo:

"One lesson learned from the past week is that Alex needs to stop using
his personal repository on fdo.
We were asked a couple of times if I couldn't update a branch there from
different directions, which we obviously can't do."

https://lists.freedesktop.org/archives/dri-devel/2017-May/142376.html
https://lists.freedesktop.org/archives/dri-devel/2017-May/142380.html
The important point being that Christian reviewed that patch and
explicitly asked Daniel to pick it up.
Wow, wait a second. I'm just catching up on this thread.

Lukas didn't committed the patch to drm-misc without a review, didn't you?

I was intentionally holding back a rb because that isn't my field of
expertise and I was only briefly involved in the original patch.
It would have been helpful if you had communicated that, I explicitly
asked Alex which tree he'd prefer merging through.  If you're his
stand-in then why didn't you reply?

Alex will be back before the weekend and probably sending another fixes pull for the rc.

PowerXpress is not my field of expertise, but Alex is deeply into so I've ignore that issue for now.

I was already wondering why you took the time to reply to Daniel's patch
(which went into drm-misc-next, so queued for 4.13), but didn't reply
at all to my patch (which affects 4.12, so arguably has higher priority).

I'd dispute that the issue at hand requires specific domain knowlege,
it's a trivial dereference of a pointer before it's set.

After taking the time this morning to take a look at the patch and the original code I can confirm that it is indeed completely trivial.

Alex should
be back by the end of the week, so no need for a rush like that.
End of the week means the patch would miss another rc cycle, and the
DRM subsystem is getting enough criticism for causing regressions as
it is, isn't it? :-(

Yeah, but in this case just ping me and not commit without any peer review.

For stuff like this we will get even more criticism from Linus than causing regressions.

Anyway no harm done, let's just merge this one through drm-misc-fixes and everything is fine.

Regards,
Christian.


Thanks,

Lukas


_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux