On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling wrote:
>
> You're right, but that's a bit fragile and convoluted. I'll fix KFD to
> handle this more robustly. See the attached (untested) patch.
Yes, this patch that makes the whole "has to use current mm" or uses
"get_task_mm()" looks good from a
On Wed, Aug 22, 2018 at 11:16 PM Zhenyu Wang wrote:
>
> yeah, that's the clear way to fix this imo. We only depend on guest
> life cycle to access guest memory properly. Here's proposed fix, will
> verify and integrate it later.
Thanks, this looks sane to me,
Linus
__
On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter wrote:
>
> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
.. because the object can be accessed (by RCU) after the refcount has
gone down to zero, and the thing has been released.
That's the whole and only point of SLAB_TY
On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds
wrote:
>
> So the re-use might initialize the fields lazily, not necessarily using a
> ctor.
In particular, the pattern that nf_conntrack uses looks like it is safe.
If you have a well-defined refcount, and use "atomic_inc_not_ze
On Tue, Dec 17, 2013 at 4:33 PM, Dave Airlie wrote:
>
> are available in the git repository at:
>
> git://people.freedesktop.org/~airlied/linux
Nope.
I assume you meant the 'drm-fixes' branch, but you didn't actually
*say* that, and when I pull it I don't get the same diffstat you
claim, so I'
On Fri, 30 Aug 2024 at 14:08, Dave Airlie wrote:
>
> The TTM revert is due to some stuttering graphical apps probably due
> to longer stalls while prefaulting.
Yeah, trying to pre-fault a PMD worth of pages in one go is just crazy talk.
Now, if it was PMD-aligned and you faulted in a single PMD,
On Mon, 2 Sept 2024 at 03:34, Christian König wrote:
>
> Am 02.09.24 um 11:32 schrieb Thomas Hellström:
> >
> > The remap_pfn_range was last tried, at least in the context of the i915
> > driver IIRC by Christoph Hellwig but had to be ripped out since it
> > requires the mmap_lock in write mode. H
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 'FB_DEFAULT_IOMEM
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... an
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 subsys
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(&dev->event_lock);
> drm_vblank_disable
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 i
On Sun, 4 Aug 2024 at 00:56, Yafang Shao wrote:
>
> There is a BUILD_BUG_ON() inside get_task_comm(), so when you use
> get_task_comm(), it implies that the BUILD_BUG_ON() is necessary.
Let's just remove that silly BUILD_BUG_ON(). I don't think it adds any
value, and honestly, it really only make
On Mon, 5 Aug 2024 at 20:01, Yafang Shao wrote:
>
> One concern about removing the BUILD_BUG_ON() is that if we extend
> TASK_COMM_LEN to a larger size, such as 24, the caller with a
> hardcoded 16-byte buffer may overflow.
No, not at all. Because get_task_comm() - and the replacements - would
ne
On Sat, 17 Aug 2024 at 01:48, Alejandro Colomar wrote:
>
> I would compact the above to:
>
> len = strlen(s);
> buf = kmalloc_track_caller(len + 1, gfp);
> if (buf)
> strcpy(mempcpy(buf, s, len), "");
No, we're not doing this kind of horror.
If _FORTIFY_SO
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, e
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 enabl
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(&r[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, th
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 i
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 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
> s
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 garba
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, t
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 interf
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
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 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 gettin
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]
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/amd
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 cleanly.
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 stupid
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 n
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 PPC_WERRO
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 worr
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 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 gnome-sess
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 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
On Fri, 14 Jun 2024 at 02:02, Pavel Machek wrote:
>
> If I can get at least basic metric on the gpu (%idle? which process
> use how much time?), it might be feasible. Is there tool similar for
> top?
Let's bring in the actual gpu people.. Dave/Jani/others - does any of
this sound familiar? Pavel
On Fri, 14 Jun 2024 at 09:21, Linus Torvalds
wrote:
>
> Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> this sound familiar? Pavel says things have gotten much slower in
> 6.10: "something was very wrong with the performance, likely to do
> with g
On Wed, 19 Jun 2024 at 03:44, Pavel Machek wrote:
>
> Ok, so machine is ready to be thrown out of window, again. Trying to
> play 29C3 video should not make machine completely unusable ... as in
> keyboard looses keystrokes in terminal.
Well, that at least sounds like you can bisect it with a ver
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
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 "->
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(), i
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
add
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
pa
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 certa
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(&dmabuf->file->f_count) != 0L;
> }
>
> If we end up adding epi_fget(), we'll have 2 cases of using
> "atomic_long_inc_not_zero"
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 ge
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 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 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 (*
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 coul
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) prac
om/
Reported-by: syzbot+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()
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 L
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 inst
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
> in
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.
epoll()
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 driver
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 w
On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote:
>
> Note this is barely tested. I intend to do more testing of next few days
> but i do not have access to all hardware that make use of the mmu_notifier
> API.
Thanks for doing this.
> First 2 patches convert existing call of mmu_notifier_in
On Thu, Feb 1, 2018 at 4:40 PM, Dave Airlie wrote:
>
> This seems to have been a comparatively quieter merge window, I assume
> due to holidays etc.
Hmm. I pulled, and then noticed that there's no diffstat to compare my
end result with.
Then I was going to at least compare the shortlog, but that
On Thu, Feb 1, 2018 at 6:22 PM, Dave Airlie wrote:
>
> Turned out I was running on wayland instead of X.org and my cut-n-paste from
> gedit to firefox got truncated, wierd. I'll go annoy some people, and make
> sure
> it doesn't happen again.
Heh, so there's some Wayland clipboard buffer limit.
This one actually seems to imply that vmw_cmd_invalid() is broken:
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:34: warning: the omitted
middle operand in ?: will always be ‘true’, suggest explicit middle
operand [-Wparentheses]
return capable(CAP_SYS_ADMIN) ? : -EINVAL;
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> - return capable(CAP_SYS_ADMIN) ? : -EINVAL;
> + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
NAK. This takes unintentionally insane code and turns it intentionally
insane. Any non-zero return is considered an error.
The right f
On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
wrote:
>
> NAK. This takes unintentionally insane code and turns it intentionally
> insane. Any non-zero return is considered an error.
>
> The right fix is almost certainly to just return -EINVAL unconditionally.
Btw, this is why
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> FIFO_MODE is an macro expression with a '<<' operator, which
> gcc points out could be misread as a '<':
Yeah, no, NAK again.
We don't make the code look worse just because gcc is being a f*cking
moron about things.
This warning is clearly
On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote:
>
> There is some code touched on sound/soc, but I think the sound tree
> should have the same commits from the same base,so this may luck different
> if you pulled it as I generated my pull request a couple of days ago.
> Otherwise
> the highli
On Thu, Nov 16, 2017 at 12:57 PM, Dave Airlie wrote:
>
> This sounds more like a Monty Python sketch than a serious question.
It's a serious question when the files start appearing in random
places where they don't belong.
There's a place for automatically generated files.
But that "there is a
On Fri, Nov 17, 2017 at 4:51 AM, Nicolai Hähnle wrote:
>
> This raises the question of how people feel about putting the source
> database into the kernel (most likely as XML in our case) and
> auto-generating the headers from there instead.
I suspect that at least in some cases, the "source" da
On Fri, Nov 17, 2017 at 9:19 AM, Lukas Wunner wrote:
>> and tell me that there isn't any room for making these things smarter.
>
> ... or deduplicate them. :-)
You could even - wait for it - have _automation_ that does it.
Yeah, it's easier to write a stupid sed-script or whatever to generate
th
On Fri, Nov 17, 2017 at 10:14 AM, Christian König
wrote:
>
> Taking an example from the AMD headers why this automation is more tricky
> than it sounds in the first place: Look at the
> mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example.
>
> Register 0-7 are consecutive and so could be perfe
On Thu, Dec 7, 2017 at 5:20 PM, Dave Airlie wrote:
>
> This pull is a bit larger than I'd like but a large bunch of it is
> license fixes, AMD wanted to fix the licenses for a bunch of files
> that were missing them,
Oh Christ, couldn't they have just added the one-liner SPDX tags
rather than doi
On Thu, Dec 14, 2017 at 6:50 AM, Daniel Vetter wrote:
>
> Imo that's enough that I figured better not delay until Dave is back.
> Linus, can you pls apply?
Pulled.
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.f
On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
>
> This didn't seem to have made it into -rc4. Anything needed to get it
> going?
Do you actually see the problem in -rc4?
Because we ended up removing the cross-release checking due to other
developers complaining. It seemed to need a lot
On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote:
> The purpose of this series is to:
> [ .. ]
The patches look ok to me and seem to make sense.
Of course, let's see what they break. Hopefully nothing, but any time
the PCI resource code changes I get a bit worried. PTSD, I guess.
On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz wrote:
>
> This same problem with X does happen in 4.5-rc7. And removing the line
> introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1 makes X go again
> on
> my laptop.
Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainlin
On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski wrote:
>
> FWIW, if I disable all the checks in pci_get_rom_size, I learn that my
> video ROM consists entirely of 0xff bytes. Maybe there just isn't a
> ROM shadow on my laptop.
I think most laptops end up having the graphics ROM be part of the
r
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 mo
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 'intel_
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 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
o
On Tue, 4 Jun 2024 at 11:25, Rodrigo Vivi wrote:
>
> (I believe that the new _match_string(str1, size, str2) deserves a better
> name,
> but since I'm bad with naming stuff, I don't have any good suggestion)
I hated the enormous cc list, so I didn't reply to all. But clearly
everybody else is ju
On Thu, 13 Jun 2024 at 14:14, Andrew Morton wrote:
>
> The concept sounds a little strange. If some code takes a copy of a
> string while some other code is altering it, yes, the result will be a
> mess. This is why get_task_comm() exists, and why it uses locking.
The thing is, get_task_comm()
On Wed, Nov 21, 2012 at 6:34 PM, Dave Airlie wrote:
>
> its vmware/nouveua/radeon/intel/ttm scattered.
Hmm. That's not what I see. I just see nouveau and soem PCI ID addition.
> 21 files changed, 108 insertions(+), 31 deletions(-)
I get
14 files changed, 70 insertions(+), 21 deletions(-)
pr
[ Hmm. For some reason this seems to have never gone out, and was in
my drafts folder. If you get it twice, my bad ]
On Thu, Nov 22, 2012 at 12:57 AM, Dave Airlie wrote:
>
> Doh!, yes I picked wrong place to generate report from, okay here is
> one corresponding to what you saw,
You should never
On Wed, Oct 3, 2012 at 9:08 PM, Dave Airlie wrote:
>
> So this pull is for my drm-next-merged branch which is my drm-next branch
> merged with your tree, and some fixups applied to the merge.
Ok, as usual I actually wanted to do the merge myself despite the
annoying conflicts (this *really* is th
Added more appropriate people to this. Added both i915 and nouveau
people, since apparently that fine piece of hardware has both.
Guys, any ideas?
Pawe?, could you perhaps get a photo of the oops and post it
somewhere? I'm assuming the oops happens early during boot and you
never get a usable mac
On Fri, Oct 19, 2012 at 3:41 PM, Martin Peres wrote:
>
> You must have missed the oops that was attached to the mail:
> http://www.spinics.net/lists/kernel/msg1420355.html
I did indeed. So never mind about that dmesg request, Pawe? ;-p
> Pawe?, could you try the attached patch please ?
Thanks f
On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
wrote:
>
> This looks like ACPI bug...
I'm _shocked_ to hear that firmware would be fragile.
Anyway, here's the #1 thing to keep in mind about firmware:
- firmware is *always* buggy.
It's that simple. Don't expect anything else. Firmware is writ
On Sun, Oct 21, 2012 at 5:49 PM, Marcin Slusarz
wrote:
>
> I know. But this bug is not about broken firmware. It's about Linux kernel
> ACPI implementation, which (I think) wrongly interprets ACPI script.
Hmm. Len, care to comment? Marcin quoted the AML and our arguments in
an earlier thing. I do
[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]
On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan wrote:
> Ping!
>
> No X for me with 3.6-rc2.
Can you possibly bisect it, at least par
On Wed, Nov 21, 2012 at 6:34 PM, Dave Airlie wrote:
>
> its vmware/nouveua/radeon/intel/ttm scattered.
Hmm. That's not what I see. I just see nouveau and soem PCI ID addition.
> 21 files changed, 108 insertions(+), 31 deletions(-)
I get
14 files changed, 70 insertions(+), 21 deletions(-)
pr
[ Hmm. For some reason this seems to have never gone out, and was in
my drafts folder. If you get it twice, my bad ]
On Thu, Nov 22, 2012 at 12:57 AM, Dave Airlie wrote:
>
> Doh!, yes I picked wrong place to generate report from, okay here is
> one corresponding to what you saw,
You should never
On Thu, Jan 24, 2013 at 4:42 PM, Dave Airlie wrote:
>
> These patches have been sailing around long enough, waiting for a maintainer
> to reappear, so I've decided enough is enough, lockdep is kinda useful to
> have.
Last this was tried, these patches failed miserably.
They caused instant lockd
On Thu, Jan 24, 2013 at 5:45 PM, Dave Airlie wrote:
>
> Okay I've just sent out another fbcon patch to fix the locking harder.
>
> There was a path going into set_con2fb_path if an fb driver was
> already registered, I just pushed the locking out further on anyone
> going in there.
>
> it boots on
On Thu, Jan 31, 2013 at 9:19 AM, Russell King wrote:
>
> So... what you seem to be telling me is that 3.9 is going to be a
> release which issues lockdep complaints when the console blanks, and
> you think that's acceptable?
>
> Adding Linus and Andrew so they're aware of this issue...
Oh, we're
On Thu, Jan 31, 2013 at 11:13 AM, Russell King wrote:
>
> Which may or may not be a good thing depending how you look at it; it
> means that once your kernel blanks, you get a lockdep dump. At that
> point you lose lockdep checking for everything else because lockdep
> disables itself after the f
[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]
On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan wrote:
> Ping!
>
> No X for me with 3.6-rc2.
Can you possibly bisect it, at least par
301 - 400 of 765 matches
Mail list logo
