On Fri, 17 May 2024 at 06:55, Alex Deucher wrote:
>
> Can you try this patch?
> https://patchwork.freedesktop.org/patch/594539/
Ack. This seems to fix it for me - unless the problem is random and
only happens sometimes, and I've just been *very* unlucky until now.
Linus
On Thu, 16 May 2024 at 18:08, Dave Airlie wrote:
>
> Linus, do you see it a boot straight away?
Ok, back at that computer now, and yes, I see those messages right
away. In fact, they seem to happen before gnome even starts up, ie I
see those messages long before the first messages from
On Wed, 15 May 2024 at 19:54, Dave Airlie wrote:
>
> Here is the buddy allocator fix I picked up from the list, please apply.
So I removed my reverts, and am running a kernel that includes the
merge 972a2543e3dd ("Merge tag 'drm-next-2024-05-16' of
https://gitlab.freedesktop.org/drm/kernel;) but
On Wed, 15 May 2024 at 16:51, Dave Airlie wrote:
>
> > Let's see if the machine ends up being stable now. It took several
> > hours for the "scary messages" state to turn into the "hung machine"
> > state, so they *could* have been independent issues, but it seems a
> > bit unlikely.
>
> This
On Wed, 15 May 2024 at 16:17, Dave Airlie wrote:
>
> It's also possible it's just that hey there's a few others in the tree
>
> KVM_WERROR not tied to it
> PPC_WERROR (why does CXL uses this?)
Yeah, that should be fixed too, but at least KVM_WERROR predates the
whole-kernel WERROR.
And
On Wed, 15 May 2024 at 15:45, Dave Airlie wrote:
>
> The drm subsystem enables more warnings than the kernel default, so
> this config option is disabled by default.
Irrelevant.
If the *main* CONFIG_WERROR is on, then it does NOT MATTER if somebody
sets CONFIG_DRM_WERROR or
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> This is the main pull request for the drm subsystems for 6.10.
.. and now that I look more at this pull request, I find other things wrong.
Why is the DRM code asking if I want to enable -Werror? I have Werror
enabled *already*.
I hate
On Wed, 15 May 2024 at 13:24, Linus Torvalds
wrote:
>
> I have to revert both
>
> a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
>
> to make things build clea
On Wed, 15 May 2024 at 13:21, Linus Torvalds
wrote:
>
> I guess I'll try to revert the later commit that enables it for amdgpu
> (commit a68c7eaa7a8f) and see if it at least makes the horrendous
> messages go away.
I have to revert both
a68c7eaa7a8f ("drm/amdgpu:
On Wed, 15 May 2024 at 13:06, Linus Torvalds
wrote:
>
> Hmm. There's something seriously wrong with amdgpu.
>
> I'm getting a ton of__force_merge warnings:
>
> WARNING: CPU: 0 PID: 1069 at drivers/gpu/drm/drm_buddy.c:199
> __force_merge+0x14f/0x180 [drm_buddy]
A
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> In drivers the main thing is a new driver for ARM Mali firmware based
> GPUs, otherwise there are a lot of changes to amdgpu/xe/i915/msm and
> scattered changes to everything else.
Hmm. There's something seriously wrong with amdgpu.
I'm
On Thu, 9 May 2024 at 04:39, Christian Brauner wrote:
>
> Not worth it without someone explaining in detail why imho. First pass
> should be to try and replace kcmp() in scenarios where it's obviously
> not needed or overkill.
Ack.
> I've added a CLASS(fd_raw) in a preliminary patch since we'll
On Wed, 8 May 2024 at 09:19, Linus Torvalds
wrote:
>
> So since we already have two versions of F_DUPFD (the other being
> F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend
> on that existing naming pattern, and called it F_DUPFD_QUERY instead.
>
> I'm not m
On Tue, 7 May 2024 at 12:07, Linus Torvalds
wrote:
>
> That example thing shows that we shouldn't make it a FISAME ioctl - we
> should make it a fcntl() instead, and it would just be a companion to
> F_DUPFD.
>
> Doesn't that strike everybody as a *much* cleaner interface? I thi
On Tue, 7 May 2024 at 11:04, Daniel Vetter wrote:
>
> On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
>
> > I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl
> > too, if this is possibly a more common thing. and not just DRM wants
On Tue, 7 May 2024 at 04:03, Daniel Vetter wrote:
>
> It's really annoying that on some distros/builds we don't have that, and
> for gpu driver stack reasons we _really_ need to know whether a fd is the
> same as another, due to some messy uniqueness requirements on buffer
> objects various
On Mon, 6 May 2024 at 10:46, Stefan Metzmacher wrote:
>
> I think it's a very important detail that epoll does not take
> real references. Otherwise an application level 'close()' on a socket
> would not trigger a tcp disconnect, when an fd is still registered with
> epoll.
Yes, exactly.
On Sun, 5 May 2024 at 13:30, Al Viro wrote:
>
> 0. special-cased ->f_count rule for ->poll() is a wart and it's
> better to get rid of it.
>
> 1. fs/eventpoll.c is a steaming pile of shit and I'd be glad to see
> git rm taken to it. Short of that, by all means, let's grab reference
>
On Sun, 5 May 2024 at 13:02, David Laight wrote:
>
> How much is the extra pair of atomics going to hurt performance?
> IIRC a lot of work was done to (try to) make epoll lockless.
If this makes people walk away from epoll, that would be absolutely
*lovely*. Maybe they'd start using io_uring
On Sun, 5 May 2024 at 12:46, Al Viro wrote:
>
> I've no problem with having epoll grab a reference, but if we make that
> a universal requirement ->poll() instances can rely upon,
Al, we're note "making that a requirement".
It always has been.
Otgherwise, the docs should have shouted out DAMN
bot+045b454ab35fd82a3...@syzkaller.appspotmail.com
Reviewed-by: Jens Axboe
Signed-off-by: Linus Torvalds
---
Changes since v1:
- add Link, Reported-by, and Jens' reviewed-by. And sign off on it
because it looks fine to me and we have some testing now.
- move epi_fget() closer to the user
- m
On Sun, 5 May 2024 at 03:50, Christian Brauner wrote:
>
> And I agree with you that for some instances it's valid to take another
> reference to a file from f_op->poll() but then they need to use
> get_file_active() imho and simply handle the case where f_count is zero.
I think this is
(a)
On Sat, 4 May 2024 at 08:32, Linus Torvalds
wrote:
>
> Lookie here, the fundamental issue is that epoll can call '->poll()'
> on a file descriptor that is being closed concurrently.
Thinking some more about this, and replying to myself...
Actually, I wonder if we could
On Sat, 4 May 2024 at 08:40, Linus Torvalds
wrote:
>
> And maybe it's even *only* dma-buf that does that fget() in its
> ->poll() function. Even *then* it's not a dma-buf.c bug.
They all do in the sense that they do
poll_wait
-> __pollwait
-> get_file (*boom*)
bu
On Sat, 4 May 2024 at 08:32, Linus Torvalds
wrote:
>
> Now, during this TOTALLY INNOCENT sock_poll(), in another thread, the
> file closing completes, eventpoll_release() finishes [..]
Actually, Al is right that ep_item_poll() should be holding the
ep->mtx, so event
On Sat, 4 May 2024 at 02:37, Christian Brauner wrote:
>
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -244,13 +244,18 @@ static __poll_t dma_buf_poll(struct file *file,
> poll_table *poll)
> if (!dmabuf || !dmabuf->resv)
> return EPOLLERR;
>
> +
On Fri, 3 May 2024 at 16:39, Al Viro wrote:
>
> *IF* those files are on purely internal filesystem, that's probably
> OK; do that with something on something mountable (char device,
> sysfs file, etc.) and you have a problem with filesystem staying
> busy.
Yeah, I agree, it's a bit annoying in
On Fri, 3 May 2024 at 16:23, Kees Cook wrote:
>
> static bool __must_check get_dma_buf_unless_doomed(struct dma_buf *dmabuf)
> {
> return atomic_long_inc_not_zero(>file->f_count) != 0L;
> }
>
> If we end up adding epi_fget(), we'll have 2 cases of using
> "atomic_long_inc_not_zero" for
On Fri, 3 May 2024 at 15:07, Al Viro wrote:
>
> Suppose your program calls select() on a pipe and dmabuf, sees data to be read
> from pipe, reads it, closes both pipe and dmabuf and exits.
>
> Would you expect that dmabuf file would stick around for hell knows how long
> after that? I would
On Fri, 3 May 2024 at 14:45, Al Viro wrote:
>
> How do you get through eventpoll_release_file() while someone
> has entered ep_item_poll()?
Doesn't matter.
Look, it's enough that the file count has gone down to zero. You may
not even have gotten to eventpoll_release_file() yet - the important
On Fri, 3 May 2024 at 14:36, Al Viro wrote:
>
> ... the last part is no-go - poll_wait() must be able to grab a reference
> (well, the callback in it must)
Yeah. I really think that *poll* itself is doing everything right. It
knows that it's called with a file pointer with a reference, and it
On Fri, 3 May 2024 at 14:24, Al Viro wrote:
>
> Can we get to ep_item_poll(epi, ...) after eventpoll_release_file()
> got past __ep_remove()? Because if we can, we have a worse problem -
> epi freed under us.
Look at the hack in __ep_remove(): if it is concurrent with
eventpoll_release_file(),
On Fri, 3 May 2024 at 14:11, Al Viro wrote:
>
> What we need is
> * promise that ep_item_poll() won't happen after
> eventpoll_release_file().
> AFAICS, we do have that.
> * ->poll() not playing silly buggers.
No. That is not enough at all.
Because even with perfectly normal
epoll is a mess, and does various invalid things in the name of
performance.
Let's try to rein it in a bit. Something like this, perhaps?
Not-yet-signed-off-by: Linus Torvalds
---
This is entirely untested, thus the "Not-yet-signed-off-by". But I
think this may be kind of the
On Tue, 12 Mar 2024 at 21:07, Dave Airlie wrote:
>
> I've done a trial merge into your tree from a few hours ago, there
> are definitely some slighty messy conflicts, I've pushed a sample
> branch here:
I appreciate your sample merges since I like verifying my end result,
but I think your merge
On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
>
> I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
> should be done. Still, we would like to help people, who are interested in
> this kind of thing, to set it up. How about we reframe this contribution as a
>
On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
>
> However, I think a better approach would be *not* to add the .gitlab-ci.yaml
> file in the root of the source tree, but instead change the very same repo
> setting to point to a particular entry YAML, *inside* the repo (somewhere
> under
On Sun, 25 Feb 2024 at 08:53, David Laight wrote:
>
> The expansions of min() and max() contain statement expressions so are
> not valid for static intialisers.
> min_const() and max_const() are expressions so can be used for static
> initialisers.
I hate the name.
Naming shouldn't be about an
On Thu, 22 Feb 2024 at 09:36, Daniel Latypov wrote:
>
> Copying the line for context, it's about `p-r` where
> p = memchr_inv([1], 0, sizeof(r) - sizeof(r[0]));
> `p-r` should never be negative unless something has gone horribly
> horribly wrong.
Sure it would - if 'p' is NULL.
Of course,
On Wed, 21 Feb 2024 at 21:05, Lucas De Marchi wrote:
>
> this has a potential to cause conflicts with upcoming work, so I think
> it's better to apply this through drm-xe-next. Let me know if you agree.
I disagree. Violently.
For this to be fixed, we need to have the printf format checking
On Sun, 28 Jan 2024 at 14:22, David Laight wrote:
>
> H blame gcc :-)
I do agree that the gcc warning quoting is unnecessarily ugly (even
just visually), but..
> The error message displays as '0' but is e2:80:98 30 e2:80:99
> I HATE UTF-8, it wouldn't be as bad if it were a bijection.
No,
On Sun, 28 Jan 2024 at 11:36, David Laight wrote:
>
> However it generates:
> error: comparison of constant ‘0’ with boolean expression is always true
> [-Werror=bool-compare]
> inside the signedness check that max() does unless a '+ 0' is added.
Please fix your locale. You have random
On Mon, 22 Jan 2024 at 16:56, Bhardwaj, Rajneesh
wrote:
>
> I think a fix might already be in flight. Please see Linux-Kernel Archive:
> Re: [PATCH] drm/ttm: fix ttm pool initialization for no-dma-device drivers
> (iu.edu)
Please use lore.kernel.org that doesn't corrupt whitespace in patches
On Mon, 22 Jan 2024 at 15:17, Steven Rostedt wrote:
>
> Perhaps this is the real fix?
If you send a signed-off version, I'll apply it asap.
Thanks,
Linus
On Wed, 10 Jan 2024 at 11:49, Dave Airlie wrote:
>
> Let me know if there are any issues,
Your testing is seriously lacking.
This doesn't even build. The reason seems to be that commit
b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with
ref_tracker library") changed the
On Wed, 3 Jan 2024 at 18:30, Dave Airlie wrote:
>
> These were from over the holiday period, mainly i915, a couple of
> qaic, bridge and an mgag200.
>
> I have a set of nouveau fixes that I'll send after this, that might be
> too rich for you at this point.
>
> I expect there might also be some
On Sat, 25 Nov 2023 at 22:58, Helge Deller wrote:
>
> please pull some small fbdev fixes for 6.7-rc3.
These all seem to be pure cleanups, not bug fixes.
Please resend during the merge window.
Linus
So every time I push to my github mirror, github now ends up having a
'dependabot' thing that warns about some of the CI version
requirements for the gitlab automated testing file.
It wants to update the pip requirements from 23.2.1 to 23.3
- When installing a package from a Mercurial VCS URL,
On Wed, 13 Sept 2023 at 07:21, Tetsuo Handa
wrote:
>
> Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
> It looks like this locking pattern remains as of 6.6-rc1. Please fix.
>
> void drm_crtc_vblank_off(struct drm_crtc *crtc) {
> spin_lock_irq(>event_lock);
>
On Wed, 30 Aug 2023 at 18:00, Dave Airlie wrote:
>
> This is a PR to add drm-ci support files to the upstream tree.
So I finally had no other pull requests pending, and spent some time
looking at this, and I see nothing offensive.
I did wonder how this then expands to having more than one
On Thu, 7 Sept 2023 at 19:45, Dave Airlie wrote:
>
> Just a poke about the outstanding drm CI support pull request since I
> haven't see any movement on that in the week, hopefully it's not as
> difficult a problem as bcachefs :-)
I was assuming that it wouldn't interfere with anything else...
On Thu, 31 Aug 2023 at 11:48, Sudip Mukherjee (Codethink)
wrote:
> The latest mainline kernel branch fails to build mips jazz_defconfig with
> the error:
>
> drivers/video/fbdev/g364fb.c:115:9: error: 'FB_DEFAULT_IOMEM_HELPERS'
> undeclared here (not in a function); did you mean
On Thu, 27 Jul 2023 at 19:20, Dave Airlie wrote:
>
> Regular scheduled fixes, msm and amdgpu leading the way, with some
> i915 and a single misc fbdev, all seems fine.
Pulled.
Tangentially related: where do you keep your pgp key? The one I have
is long expired, and doing a refresh doesn't get
On Fri, 23 Jun 2023 at 14:18, Alex Deucher wrote:
>
> are available in the Git repository at:
>
> https://gitlab.freedesktop.org/agd5f/linux.git
> tags/amd-drm-fixes-6.4-2023-06-23
That's not a valid signed tag.
Yes, it's a tag. But it doesn't actually have any cryptographic
signing, and
On Wed, Apr 26, 2023 at 10:44 AM Sudip Mukherjee (Codethink)
wrote:
>
> drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified
> 'global_write_combined' at file scope
>73 | static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> |
Kees,
I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
in the process I got gcc-13 which is not WERROR-clean because we only
limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
has all the same issues.
And I want to be able to do my arm64 builds with WERROR on
On Wed, Mar 22, 2023 at 9:40 AM Sedat Dilek wrote:
>
> You have to pass `make LLVM=1` in any case... to `oldconfig` or when
> adding any MAKEFLAGS like -j${number-of-available-cpus}.
I actually think we should look (again) at just making the compiler
choice (and the prefix) be a Kconfig option.
On Mon, Mar 20, 2023 at 3:06 PM Nathan Chancellor wrote:
>
> Right, this seems like a subtle difference in semantics between
> -Wuninitialized between clang and GCC.
I guess it's a bit ambiguous whether it's
"X may be USED uninitialized"
or whether it is
"X may BE uninitialized"
and then
On Mon, Mar 20, 2023 at 1:05 PM Guenter Roeck wrote:
>
> I have noticed that gcc doesn't always warn about uninitialized variables
> in most architectures.
Yeah, I'm getting the feeling that when the gcc people were trying to
make -Wmaybe-uninitialized work better (when moving it into "-Wall"),
On Mon, Mar 20, 2023 at 11:56 AM Nathan Chancellor wrote:
>
> I did see a patch fly by to fix that:
>
> https://lore.kernel.org/20230316082035.567520-3-christian.koe...@amd.com/
>
> It seems like the DRM_TEGRA half of it is broken though:
>
>
On Mon, Mar 20, 2023 at 11:26 AM Linus Torvalds
wrote:
>
> Hmm. I do my arm64 allmodconfig builds with gcc, and I'm surprised
> that gcc doesn't warn about this.
Side note: I'm also wondering why that TEGRA_HOST1X config has that
ARM dependency in
depends on ARCH_TEGR
On Mon, Mar 20, 2023 at 11:05 AM Nathan Chancellor wrote:
>
> On the clang front, I am still seeing the following warning turned error
> for arm64 allmodconfig at least:
>
> drivers/gpu/host1x/dev.c:520:6: error: variable 'syncpt_irq' is
> uninitialized when used here [-Werror,-Wuninitialized]
On Wed, Mar 15, 2023 at 5:22 PM Steven Rostedt wrote:
>
> I hope that this gets in by -rc3, as I want to start basing my next branch
> on that tag.
My tree should have it now as commit c00133a9e87e ("drm/ttm: drop
extra ttm_bo_put in ttm_bo_cleanup_refs").
Linus
On Thu, Mar 16, 2023 at 4:43 AM Matthieu Baerts
wrote:
>
> @Linus: in short, we would like to continue using the "Closes:" tag (or
> similar, see below) with a URL in commit messages. They are useful to
> have public bug trackers doing automated actions like closing a specific
> ticket. Any
On Fri, Feb 24, 2023 at 5:30 PM Dave Airlie wrote:
>
> Any issues with this? I get nervous around 48hrs :-)
It was merged on Wednesday evening. See commit a5c95ca18a98.
If you were waiting for a pr-tracker-bot reply, I think you need to
put "{GIT PULL]" in the subject line for the automation to
[ Back from travel, so trying to make sense of this series.. ]
On Sun, Jan 8, 2023 at 7:33 PM Byungchul Park wrote:
>
> I've been developing a tool for detecting deadlock possibilities by
> tracking wait/event rather than lock(?) acquisition order to try to
> cover all synchonization machanisms.
On Wed, Dec 14, 2022 at 12:05 AM Christian König
wrote:
>
> Anyway we need to re-apply b09d6acba1d9 which should be trivial.
Note that my resolution did exactly that (*), it's just that when I
double-checked against Dave's suggested merge that I noticed I'd done
things differently than he did.
On Mon, Dec 12, 2022 at 6:56 PM Dave Airlie wrote:
>
> There are a bunch of conflicts, one in amdgpu is a bit nasty, I've
> cc'ed Christian/Alex to make sure they know to check whatever
> resolution you find. The one I have is what we have in drm-tip tree.
Hmm. My merge resolution is slightly
On Tue, Nov 22, 2022 at 4:25 AM Hans Verkuil wrote:
>
> I tracked the use of 'force' all the way back to the first git commit
> (2.6.12-rc1) in the very old video-buf.c. So it is very, very old and the
> reason is lost in the mists of time.
Well, not entirely.
For archaeology reasons, I went
On Thu, Nov 17, 2022 at 2:58 PM Kees Cook wrote:
>
> Oh, er, why does get_arg_page() even need FOLL_FORCE? This is writing the
> new stack contents to the nascent brpm->vma, which was newly allocated
> with VM_STACK_FLAGS, which an arch can override, but they all appear to
> include
> VM_WRITE |
On Wed, Nov 16, 2022 at 2:30 AM David Hildenbrand wrote:
>
> Let's make it clearer that functionality provided by FOLL_FORCE is
> really only for ptrace access.
I'm not super-happy about this one.
I do understand the "let's rename the bit so that no new user shows up".
And it's true that the
On Mon, Nov 7, 2022 at 8:18 AM David Hildenbrand wrote:
>
> So instead, make R/O long-term pinning work as expected, by breaking COW
> in a COW mapping early, such that we can remove any FOLL_FORCE usage from
> drivers.
Nothing makes me unhappy from a quick scan through these patches.
And I'd
On Sat, Nov 5, 2022 at 2:03 PM Jason A. Donenfeld wrote:
>
> Something that might help here is changing the `...` into
> `... when exists` or into `... when != ptr` or similar.
I actually tried that.
You don't want "when exists", you'd want "when forall", but that seems
to be the default.
And
On Sat, Nov 5, 2022 at 11:04 AM Steven Rostedt wrote:
>
> Here's the changes I made after running the script
Please. No.
What part of "I don't want extra crud" was I unclear on?
I'm not interested in converting everything. That's clearly a 6.,2
issue, possibly even longer considering how
On Fri, Nov 4, 2022 at 11:01 PM Steven Rostedt wrote:
>
> Patch 1 fixes an issue with sunrpc/xprt where it incorrectly uses
> del_singleshot_timer_sync() for something that is not a oneshot timer. As this
> will be converted to shutdown, this needs to be fixed first.
So this is the kind of thing
On Fri, Nov 4, 2022 at 12:42 PM Steven Rostedt wrote:
>
> Linus, should I also add any patches that has already been acked by the
> respective maintainer?
No, I'd prefer to keep only the ones that are 100% unambiguously not
changing any semantics.
Linus
On Thu, Nov 3, 2022 at 10:48 PM Steven Rostedt wrote:
>
> Ideally, I would have the first patch go into this rc cycle, which is mostly
> non functional as it will allow the other patches to come in via the
> respective
> subsystems in the next merge window.
Ack.
I also wonder if we could do
On Fri, Oct 14, 2022 at 8:22 AM Nathan Chancellor wrote:
>
> After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr
> transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
> misplaced brace, along the lines of:
Thanks, applied.
Linus
On Thu, Oct 13, 2022 at 5:29 PM Dave Airlie wrote:
>
> Round of fixes for the merge window stuff, bunch of amdgpu and i915
> changes, this should have the gcc11 warning fix, amongst other
> changes.
Some of those amd changes aren't "fixes". They are some major code changes.
We're still in the
On Thu, Oct 6, 2022 at 1:50 PM Sudip Mukherjee
wrote:
>
> > And it looks like Sudip's proposed fix for this particular code is
> > additionally fixing unsigned vs signed as well. I think -Warray-bounds
> > did its job (though, with quite a confusing index range in the report).
>
> Not my.
On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
>
>
> [ 1234.778760] BUG: kernel NULL pointer dereference, address: 0088
> [ 1234.778813] RIP: 0010:drm_sched_job_done.isra.0+0xc/0x140 [gpu_sched]
As far as I can tell, that's the line
struct drm_gpu_scheduler *sched =
On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher wrote:
>
> Maybe you are seeing this which is an issue with GPU TLB flushes which
> is kind of sporadic:
> https://gitlab.freedesktop.org/drm/amd/-/issues/2113
Well, that seems to be 5.19, and while timing changes (or whatever
other software updates)
On Thu, Oct 6, 2022 at 12:30 PM Dave Airlie wrote:
>
> netconsole?
I've never been really successful with that in the past, and haven't
used it for decades. I guess I could try if nothing else works.
Linus
On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink)
wrote:
>
> This is only seen with gcc-11, gcc-12 builds are ok.
Hmm. This seems to be some odd gcc issue.
I *think* that what is going on is that the test
j = 0 ; j < MAX_DWB_PIPES
makes gcc decide that "hey, j is in the range
On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
>
> Lots of stuff all over, some new AMD IP support and gang
> submit support [..]
Hmm.
I have now had my main desktop lock up twice after pulling this.
Nothing in the dmesg after a reboot, and nothing in particular that
seems to trigger it, so
On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
>
> This is very conflict heavy, mostly the correct answer is picking
> the version from drm-next.
Ugh, yes, that was a bit annoying.
I get the same end result as you did, but I do wonder if the drm
people should try to keep some kind of
On Wed, Sep 28, 2022 at 1:15 AM Gwan-gyeong Mun
wrote:
>
> + if (check_assign(obj->base.size >> PAGE_SHIFT, ))
> + return -E2BIG;
I have to say, I find that new "check_assign()" macro use to be disgusting.
It's one thing to check for overflows.
It's another thing entirely
On Sun, Aug 7, 2022 at 10:36 AM David Laight wrote:
>
> Or just shoot the software engineer who thinks 100 arguments
> is sane. :-)
I suspect the issue is that it's not primarily a software engineer who
wrote that code.
Hardware people writing code are about as scary as software engineers
with
On Thu, Aug 4, 2022 at 1:43 PM Nathan Chancellor wrote:
>
> I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size
> in the mode support function") did have a workaround for GCC. It appears
> clang will still inline mode_support_configuration(). If I mark it as
> 'noinline', the
On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
wrote:
>
> git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
> display engine with KCOV enabled").
Ahh. So that was presumably why it was disabled before - because it
presumably does disgusting things that make
On Wed, Aug 3, 2022 at 10:50 PM Dave Airlie wrote:
>
> With this applied, I get gdm back.
I can confirm that it makes thing work again for me too. Applied.
Linus
On Thu, Aug 4, 2022 at 12:35 AM Sudip Mukherjee (Codethink)
wrote:
>
> I will be happy to test any patch or provide any extra log if needed.
It sounds like that file just needs to get a
#include
there, and for some reason architectures other than alpha and mips end
up getting it
On Wed, Aug 3, 2022 at 9:27 PM Linus Torvalds
wrote:
>
> I'll do a few more. It's close enough already that it should be just
> four more reboots to pinpoint exactly which commit breaks.
commit 5d945cbcd4b16a29d6470a80dfb19738f9a4319f is the first bad commit.
I think it's suppose
On Wed, Aug 3, 2022 at 9:24 PM Dave Airlie wrote:
>
> I've reproduced it, I'll send you a revert pile when I confirm it is
> the buddy allocator.
I've bisected it to 86bd6706c404..074293dd9f61 and don't see "buddy"
in any of those commits.
I'll do a few more. It's close enough already that it
On Wed, Aug 3, 2022 at 8:53 PM Dave Airlie wrote:
>
> > It works on my intel laptop, so it's amdgpu somewhere.
>
> I'll spin my ryzen up to see if I can reproduce, and test against the
> drm-next pre-merge tree as well.
So it's not my merge - I've had a bad result in the middle of the DRM
On Wed, Aug 3, 2022 at 8:37 PM Dave Airlie wrote:
>
> Actually I did miss that so that looks good.
.. I wish it did, but I just actually test-booted my desktop with the
result, and it crashes the X server. This seems to be the splat in
Xorg.0.log:
(II) Initializing extension DRI2
(II)
On Wed, Aug 3, 2022 at 7:46 PM Linus Torvalds
wrote:
>
> I think I have it resolved, am still doing a full build test, and will
> then compare against what your suggested merge is.
Hmm.
I end up with *almost* the same thing.
Except I ended up with a
select
On Tue, Aug 2, 2022 at 10:38 PM Dave Airlie wrote:
>
> This is a conflicty one. The late revert in 5.19 of the amdgpu buddy
> allocator causes major conflict fallout. The buddy allocator code in
> this one works, so the resolutions are usually just to take stuff from
> this. It might actually be
On Sat, Jul 16, 2022 at 2:35 PM Linus Torvalds
wrote:
>
> That said, even those type simplifications do not fix the fundamental
> issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
> although now it's at least a "64-by-32" bit divide.
Hmm.
On Fri, Jul 15, 2022 at 2:09 PM Nathan Chancellor wrote:
>
> On Fri, Jul 15, 2022 at 01:36:17PM +1000, Dave Airlie wrote:
> > Matthew Auld (1):
> > drm/i915/ttm: fix sg_table construction
>
> This patch breaks i386_defconfig with both GCC and clang:
>
> ld:
1 - 100 of 704 matches
Mail list logo
