On Sun, Apr 11, 2021 at 2:43 PM Maciej W. Rozycki wrote:
>
> So it does trigger with vgacon and my old server, which I have started
> experimenting with and for a start I have switched to a new kernel for an
> unrelated purpose (now that I have relieved it from all its usual tasks
> except for th
I've updated to Fedora 34 on one of my machines, and it causes a lot
of i915 warnings like
drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
drivers/gpu/drm/i915/intel_pm.c:3059:9: note: referencing argument 3
of type ‘const u16 *’ {aka ‘const short unsigned int *’}
driver
On Tue, Apr 27, 2021 at 4:43 PM Linus Torvalds
wrote:
>
> I think I will make the argument type to intel_print_wm_latency() be
> just "const u16 wm[]" for now, just to avoid seeing a ton of silly
> warnings.
After fixing the trivial ones, this one remains:
driver
On Tue, Apr 27, 2021 at 8:32 PM Dave Airlie wrote:
>
> There aren't a massive amount of conflicts, only with vmwgfx when I
> did a test merge into your master yesterday, I think you should be
> able to handle them yourself, but let me know if you want me to push a
> merged tree somewhere (or if I
On Wed, Apr 28, 2021 at 11:14 AM Daniel Vetter wrote:
>
> Maybe we're overdoing it a bit, but we're trying to not backmerge all
> the time for no reason at all.
Oh, I'm not complaining. I think it's reasonable if some particular
issue doesn't hold up further development.
So my email was more a s
On Tue, Apr 27, 2021 at 8:32 PM Dave Airlie wrote:
>
> This is the main drm pull request for 5.13. The usual lots of work all
> over the place. [...]
>
> Mikita Lipski:
> drm/amd/display: Add MST capability to trigger_hotplug interface
Hmm. I've already merged this, but my clang build shows
This might possibly have been fixed already by the previous drm pull,
but I wanted to report it anyway, just in case.
It happened after an uptime of over a week, so it might not be trivial
to reproduce.
It's a NULL pointer dereference in dc_stream_retain() with the code being
lock xadd %
On Thu, Jan 14, 2021 at 2:01 PM Steven Rostedt wrote:
>
> Thanks, I take it, it will be going into mainline soon.
Just got merged - it might be a good idea to verify that your problem is solved.
Linus
___
dri-devel mailing list
dri-devel@li
On Thu, Feb 18, 2021 at 10:06 PM Dave Airlie wrote:
>
> Let me know if there are any issues,
gcc was happy, and I obviously already pushed out my merge, but then
when I did my clang build afterwards, it reports:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:764:2: warning:
variable 'structu
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
>
> Cc all the mailing lists ... my usual script crashed and I had to
> hand-roll the email and screwed it up ofc :-/
Oh, and my reply thus also became just a reply to you personally.
So repeating it here, in case somebody has comments about t
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
>
> Cc all the mailing lists ... my usual script crashed and I had to
> hand-roll the email and screwed it up ofc :-/
Oh, and you also didn't get a pr-tracker-bot response for this for the
same reason.
Even your fixed email was ignored by the
[ You had a really odd Reply-to on this one ]
On Mon, May 3, 2021 at 12:15 PM Daniel Vetter wrote:
>
> Anyway here's a small pull for you to ponder, now that the big ones are
> all through.
Well, _now_ I'm all caught up. Knock wood. Anyway, time to look at it:
> Follow-up to my pull from last m
[ Daniel, please fix your broken email setup. You have this insane
"Reply-to" list that just duplicates all the participants. Very
broken, very annoying ]
On Fri, May 7, 2021 at 8:53 AM Daniel Vetter wrote:
>
> So personally I think the entire thing should just be thrown out, it's all
> levels of
stery, and I haven't heard anything otherwise, so there it is.
Linus
On Wed, Apr 28, 2021 at 12:27 AM Jani Nikula wrote:
>
> On Tue, 27 Apr 2021, Linus Torvalds wrote:
> > I've updated to Fedora 34 on one of my machines, and it causes a lot
> > of i915 w
On Sun, May 9, 2021 at 11:16 AM Dave Airlie wrote:
>
> Bit later than usual, I queued them all up on Friday then promptly
> forgot to write the pull request email. This is mainly amdgpu fixes,
> with some radeon/msm/fbdev and one i915 gvt fix thrown in.
Hmm. Gcc seems ok with this, but clang comp
On Fri, May 14, 2021 at 9:20 AM Tetsuo Handa
wrote:
>
> Currently it is impossible to control upper limit of rows/columns values
> based on amount of memory reserved for the graphical screen, for
> resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
> already KD_GRAPHICS
Hone
On Fri, May 14, 2021 at 10:29 AM Linus Torvalds
wrote:
>
> So why not just say "that clearly already doesn't work, so make it
> explicitly not permitted"?
IOW, something like this would seem fairly simple and straightforward:
diff --git a/drivers/tty/vt/vt.c b/dri
On Thu, May 13, 2021 at 7:34 PM Dave Airlie wrote:
>
> Just realised I got the tag header wrong, these are the rc2 fixes.
Heh. The tag message also says:
> vc4:
> - drop an used function
which just makes me think you may have started drinking early ;)
I fixed it up. Skål!
Lin
On Fri, May 14, 2021 at 10:37 AM Linus Torvalds
wrote:
>
> IOW, something like this would seem fairly simple and straightforward:
Proper patch in case syzbot can test this..
Linus
From b33ca195cecea478768de353b3ae976c07a65615 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
On Fri, May 14, 2021 at 1:25 PM Maciej W. Rozycki wrote:
>
> Overall I think it does make sense to resize the text console at any
> time, even if the visible console (VT) chosen is in the graphics mode,
It might make sense, but only if we call the function to update the
low-level data.
Not call
On Fri, May 14, 2021 at 1:32 PM Linus Torvalds
wrote:
>
> Another alternative would be to just delay the resize to when vcmode
> is put back to text mode again. That sounds somewhat reasonable to me,
> but it's a pretty big thing.
Actually thinking more about that option, it so
On Sat, May 15, 2021 at 9:33 AM Maciej W. Rozycki wrote:
>
> NB I suggest that you request your change to be backported, i.e. post v3
> with:
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: sta...@vger.kernel.org # v2.6.12+
I've applied it to my tree, but let's wait to see that it doesn't
cau
On Mon, May 17, 2021 at 6:09 PM Sasha Levin wrote:
>
> From: Tetsuo Handa
>
> [ Upstream commit ffb324e6f874121f7dce5bdae5e05d02baae7269 ]
So I think the commit is fine, and yes, it should be applied to
stable, but it's one of those "there were three different patches in
as many days to fix the
On Wed, Jun 30, 2021 at 9:34 PM Dave Airlie wrote:
>
> Hi Linus,
>
> This is the main drm pull request for 5.14-rc1.
>
> I've done a test pull into your current tree, and hit two conflicts
> (one in vc4, one in amdgpu), both seem pretty trivial, the amdgpu one
> is recent and sfr sent out a resolu
On Mon, Jul 12, 2021 at 12:08 AM Jon Masters wrote:
>
> I happened to be installing a Fedora 34 (x86) VM for something and did a
> test kernel compile that hung on boot. Setting up a serial console I get
> the below backtrace from ttm but I have not had chance to look at it.
It's a NULL pointer i
On Tue, Nov 3, 2020 at 2:33 AM Thomas Gleixner wrote:
>
> +static inline void *kmap(struct page *page)
> +{
> + void *addr;
> +
> + might_sleep();
> + if (!PageHighMem(page))
> + addr = page_address(page);
> + else
> + addr = kmap_high(page);
> +
On Tue, Nov 3, 2020 at 2:20 PM Kirill A. Shutemov wrote:
>
> On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> > drm/nouveau/kms: Search for encoders' connectors properly
>
> This commit (09838c4efe9a) broke boot for me. These two hunks in
> particular:
Christ. It's been two we
On Sun, Nov 15, 2020 at 12:41 PM Dave Airlie wrote:
>
> As mentioned I did have a fixes pull from Ben from after I'd sent you
> out stuff, it contains the fix for the regression reported in the rc1
> thread along with two others.
Thanks, pulled,
Linus
___
On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote:
>
> I've got the 'splat' below during boot.
> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics.
> User space is Ubuntu 20.04.
>
> Additionally the X display has all the colours and alignment slightly
> messed up.
> 5.9.0 was ok.
>
On Wed, Mar 23, 2022 at 7:30 PM Dave Airlie wrote:
>
> This is the main drm pull request for 5.18.
>
> The summary changelog is below, lots of work all over,
> Intel improving DG2 support, amdkfd CRIU support, msm
> new hw support, and faster fbdev support.
Ok, so this was annoying.
I've merged
On Thu, Mar 24, 2022 at 7:13 PM Dave Airlie wrote:
>
> Some fixes were queued up in and in light of the fbdev regressions,
> I've pulled those in as well,
Thanks, pulled.
It sounds (from the other thread) that the mediatek DT issue is also
about to be fixed, even if it's not yet here.
But that
I didn't notice this until now, probably because everything still
_works_, but I get a new big warning splat at bootup on my main
workstation these days as of the merge window changes.
The full warning is attached, but it's basically the ASSERT(0) at line 938 in
drivers/gpu/drm/amd/display/dc/c
On Sun, Feb 27, 2022 at 1:54 PM Arnd Bergmann wrote:
>
> Since the differences between gnu99, gnu11 and gnu17 are fairly minimal
> and mainly impact warnings at the -Wpedantic level that the kernel
> never enables, the easiest way is to just leave out the -std=gnu89
> argument entirely, and rely o
On Sun, Feb 27, 2022 at 3:04 PM Alex Elder wrote:
>
> Glancing at the Greybus code, I don't believe there's any
> reason it needs to shift a negative value. Such warnings
> could be fixed by making certain variables unsigned, for
> example.
As mentioned in the original thread, making things unsi
On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann wrote:
>
> I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it
> make sense regardless of the -std=gnu11 change
I do think they make sense, but I want to note again that people doing
cross builds obviously use different tools for user b
On Mon, Feb 28, 2022 at 4:19 AM Christian König
wrote:
>
> I don't think that using the extra variable makes the code in any way
> more reliable or easier to read.
So I think the next step is to do the attached patch (which requires
that "-std=gnu11" that was discussed in the original thread).
T
On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds
wrote:
>
> I do wish we could actually poison the 'pos' value after the loop
> somehow - but clearly the "might be uninitialized" I was hoping for
> isn't the way to do it.
Side note: we do need *some* way to d
On Mon, Feb 28, 2022 at 12:03 PM Linus Torvalds
wrote:
>
> Side note: we do need *some* way to do it.
Ooh.
This patch is a work of art.
And I mean that in the worst possible way.
We can do
typeof(pos) pos
in the 'for ()' loop, and never use __iter at all.
That means
On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds
wrote:
>
> We can do
>
> typeof(pos) pos
>
> in the 'for ()' loop, and never use __iter at all.
>
> That means that inside the for-loop, we use a _different_ 'pos' than outside.
The thing that ma
On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote:
>
> Then we can never use -Wshadow ;-( I'd love to be able to turn it on;
> it catches real bugs.
Oh, we already can never use -Wshadow regardless of things like this.
That bridge hasn't just been burned, it never existed in the first
place.
On Mon, Feb 28, 2022 at 12:29 PM Johannes Berg
wrote:
>
> If we're willing to change the API for the macro, we could do
>
> list_for_each_entry(type, pos, head, member)
>
> and then actually take advantage of -Wshadow?
See my reply to Willy. There is no way -Wshadow will ever happen.
I conside
On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel wrote:
>
> The goal of this is to get compiler warnings right? This would indeed be
> great.
Yes, so I don't mind having a one-time patch that has been gathered
using some automated checker tool, but I don't think that works from a
long-term maintena
On Mon, Feb 28, 2022 at 3:26 PM Matthew Wilcox wrote:
>
> #define ___PASTE(a, b) a##b
> #define __PASTE(a, b) ___PASTE(a, b)
> #define _min(a, b, u) ({ \
Yeah, except that's ugly beyond belief, plus it's literally not what
we do in the kernel.
Really. The "-Wshadow doesn't work on the k
On Mon, Feb 28, 2022 at 4:45 PM Linus Torvalds
wrote:
>
> Yeah, except that's ugly beyond belief, plus it's literally not what
> we do in the kernel.
(Of course, I probably shouldn't have used 'min()' as an example,
because that is actually one of the few plac
On Mon, Feb 28, 2022 at 4:38 PM Segher Boessenkool
wrote:
>
> In C its scope is the rest of the declaration and the entire loop, not
> anything after it. This was the same in C++98 already, btw (but in
> pre-standard versions of C++ things were like you remember, yes, and it
> was painful).
Yeah
On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote:
>
> The first big glitch with -Wshadow was with shadowed global variables.
> GCC 4.8 fixed that, but it still yells about shadowed functions. What
> _almost_ works is -Wshadow=local.
Heh. Yeah, I just have long memories of "-Wshadow was a disaster"
On Mon, Feb 28, 2022 at 2:29 PM James Bottomley
wrote:
>
> However, if the desire is really to poison the loop variable then we
> can do
>
> #define list_for_each_entry(pos, head, member) \
> for (pos = list_first_entry(head, typeof(*pos), member);\
>
On Tue, Mar 1, 2022 at 11:06 AM Linus Torvalds
wrote:
>
> So instead of that simple "if (!entry)", we'd effectively have to
> continue to use something that still works with the old world order
> (ie that "if (list_entry_is_head())" model).
Just to prove my
So looking at this patch, I really reacted to the fact that quite
often the "use outside the loop" case is all kinds of just plain
unnecessary, but _used_ to be a convenience feature.
I'll just quote the first chunk in it's entirely as an example - not
because I think this chunk is particularly im
On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote:
>
> Can it be resolved by making:
> #define list_entry_is_head(pos, head, member) ((pos) == NULL)
> and double-checking that it isn't used anywhere else (except in
> the list macros themselves).
Well, yes, except for the fact that then the name i
On Tue, Mar 1, 2022 at 3:19 PM David Laight wrote:
>
> Having said that there are so few users of list_entry_is_head()
> it is reasonable to generate two new names.
Well, the problem is that the users of list_entry_is_head() may be few
- but there are a number of _other_ ways to check "was that t
On Wed, Mar 2, 2022 at 12:07 PM Kees Cook wrote:
>
> I've long wanted to change kfree() to explicitly set pointers to NULL on
> free. https://github.com/KSPP/linux/issues/87
We've had this discussion with the gcc people in the past, and gcc
actually has some support for it, but it's sadly tied to
On Mon, Aug 30, 2021 at 10:53 PM Dave Airlie wrote:
>
> There are a bunch of conflicts with your tree, but none of them seem
> too serious, but I might have missed something.
No worries. I enjoyed seeing the AMD code-names in the conflicts, they
are using positively kernel-level naming.
That sai
On Wed, Sep 1, 2021 at 10:57 AM Linus Torvalds
wrote:
>
> No worries. I enjoyed seeing the AMD code-names in the conflicts, they
> are using positively kernel-level naming.
Oh, I spoke too soon.
The conflict in amdgpu_ras_eeprom.c is trivial to fix up, but the
*code* is garbage.
It
On Tue, Sep 14, 2021 at 12:48 PM Alex Deucher wrote:
>
> On Tue, Sep 7, 2021 at 6:25 AM Christian König
> wrote:
> >
> >
> > Reviewed-by: Christian König
>
> Is one of you going to push this to drm-misc?
I was assuming it was there already.
I guess I'll just apply it directly.
Linus
On Sat, Sep 18, 2021 at 2:18 AM Michael Stapelberg
wrote:
>
> torvalds at linux-foundation.org (Linus Torvalds) writes:
> > Did I fix it up correctly? Who knows. The code makes more sense to me
> > now and seems valid. But I really *really* want to stress how locking
> >
On Sat, Sep 18, 2021 at 1:13 PM Michael Stapelberg
wrote:
>
> > Michael - do things work if you revert those two (sadly, they don't
> > revert cleanly exactly _because_ of the other changes in the same
> > area)?
>
> Reverting only 9984d6664ce9 is not sufficient, but reverting both
> 9984d6664ce9
On Sat, Sep 18, 2021 at 3:00 PM Sudip Mukherjee
wrote:
>
> Its still there. I am seeing it every night. This was from last night
> - https://lava.qa.codethink.co.uk/scheduler/job/164#L1356
Note that that web server is not available at least to me. Looks like
some internal name or limited dns, I
On Sat, Sep 18, 2021 at 3:48 PM Sudip Mukherjee
wrote:
>
> Also, I have now tested by reverting those two commits and I still get
> the same trace on rpi4.
Ok. I'm afraid we really need to have the VC4 people figure it out - I
count do the two reverts that are reported to fix the RPi3 issue, but
On Sun, Sep 19, 2021 at 4:05 AM Sudip Mukherjee
wrote:
>
> And indeed, reverting 27da370e0fb3 ("drm/vc4: hdmi: Remove
> drm_encoder->crtc usage") on top of d4d016caa4b8 ("alpha: move
> __udiv_qrnnd library function to arch/alpha/lib/")
> has fixed the error.
Ok, since your pulseaudio problem was
On Mon, Sep 20, 2021 at 5:17 AM Maxime Ripard wrote:
>
> I'm sorry, but I find that situation to be a bit ridiculous.
Honestly, the original report about the pulseaudio problem came in
over two weeks ago, and all you seemed to do was to ignore everything
that Sudip said and reported.
THAT is the
On Mon, Sep 20, 2021 at 10:33 AM Maxime Ripard wrote:
>
> What I was interested in was more about the context itself, and I'd
> still like an answer on whether it's ok to wait for a review for 5
> months though, or if it's an expectation from now on that we are
> supposed to fix bugs over the week
On Wed, Sep 22, 2021 at 3:11 AM Sudip Mukherjee
wrote:
>
> That test script is triggering the openqa job, but its running only
> after lava is able to login. The trace is appearing before the login
> prompt even, so test_mainline.sh should not matter here.
Side note: the traces might be more legi
On Wed, Sep 22, 2021 at 10:02 AM Sudip Mukherjee
wrote:
>
>
> Attached is a complete dmesg and also the decoded trace.
> This is done on 4357f03d6611 ("Merge tag 'pm-5.15-rc2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm")
drivers/gpu/drm/vc4/vc4_hdmi.c:1214 is
tmp
On Wed, Sep 22, 2021 at 1:19 PM Sudip Mukherjee
wrote:
>
> I added some debugs to print the addresses, and I am getting:
> [ 38.813809] sudip crtc
>
> This is from struct drm_crtc *crtc = connector->state->crtc;
Yeah, that was my personal suspicion, because while the line numbe
On Sat, Oct 2, 2021 at 5:17 AM Steven Rostedt wrote:
>
> On Sat, 2 Oct 2021 03:17:29 -0700 (PDT)
> Hugh Dickins wrote:
>
> > Yes (though bisection doesn't work right on this one): the fix
>
> Interesting, as it appeared to be very reliable. But I didn't do the
> "try before / after" on the patch.
On Sun, Jan 16, 2022 at 9:32 PM Helge Deller wrote:
>
> This pull request contains only one single initial patch which adds
> myself to the MAINTAINERS file for the FRAMBUFFER LAYER.
I'll pull this (as my test builds for other things complete), but this
is just a note to say that this pull reques
On Wed, Jan 19, 2022 at 2:29 PM Helge Deller wrote:
>
> >>
> >> Ah, no, that was just the soft scrollback code I was thinking of, which
>
> Right.
> That was commit 973c096f6a85 and it was about vgacon, not fbcon.
No, fbcon had some bug too, although I've paged out the details. See
commit 5014547
On Thu, Nov 11, 2021 at 7:25 PM Dave Airlie wrote:
>
> I missed a drm-misc-next pull for the main pull last week. It wasn't
> that major and isn't the bulk of this at all. This has a bunch of
> fixes all over, a lot for amdgpu and i915.
Ugh.
The i915 conflict was trivial, but made me aware of th
[ Hmm. This email was marked as spam for me. I see no obvious reason
for it being marked as spam, but it happens.. ]
On Thu, Nov 11, 2021 at 12:52 PM Sudip Mukherjee
wrote:
>
> # first bad commit: [cd7f5ca33585918febe5e2f6dc090a21cfa775b0]
> drm/virtio: implement context init: add virtio_gpu_fenc
On Sun, Nov 14, 2021 at 1:00 PM Dave Airlie wrote:
>
> i915 will no longer be x86-64 only in theory, since Intel now produces
> PCIe graphics cards using the same hw designs.
Well, at least in my tree, it still has the "depends on X86", along
with several other x86-only things (like "select INTEL
On Thu, Dec 10, 2020 at 7:52 PM Dave Airlie wrote:
>
> This is an early pull request for drm for 5.11 merge window. I'm going
> to be out for most of the first week of the merge window so thought
> I'd just preempt things and send this early.
Ok, I've merged this, and Dave is likely gone already,
On Mon, Dec 14, 2020 at 2:29 PM Alex Deucher wrote:
>
> The relevant fixes are:
Ok, I can confirm that applying those two patches gets my workstation
working properly again.
Would it be possible to get those submitted properly (or I can just
take them as-is, but would like to get a "please just
On Wed, Dec 23, 2020 at 6:29 PM Dave Airlie wrote:
>
> Xmas eve pull request present. Just some fixes that trickled in this
> past week. Mostly amdgpu fixes, with a dma-buf/mips build fix and some
> misc komeda fixes.
Well, I already pulled and pushed out my merge, but only noticed
afterwards tha
On Thu, Jan 6, 2022 at 7:23 PM Dave Airlie wrote:
>
> There is only the amdgpu runtime pm regression fix in here.
Thanks, from a quick test it works for me - the backlight actually
does eventually go away.
It does so only on the second time the monitors say "no signal, going
to power save", but
On Sun, Jan 9, 2022 at 11:38 PM Geert Uytterhoeven wrote:
>
> The commit that merged this branch made a seemingly innocent change to
> the top Makefile:
"Seemingly" innocent?
Or something darker and more sinister, related to the unrelenting
slaughter of flightless fowl?
You be the judge.
On Thu, Jan 6, 2022 at 10:12 PM Dave Airlie wrote:
>
> nouveau_fence.c is the only conflict I've seen and I've taken the result from
> our rerere cache in the merge above. It's non trivial, would be good to have
> Christian confirm it as well.
Thanks, that conflict really ended up being one that
On Thu, Jan 6, 2022 at 10:12 PM Dave Airlie wrote:
>
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-01-07
Gaah. I merged things and it built cleanly, and I pushed it out.
But then I actually *booted* it, and that's not pretty.
It *works", but it's almost unusable because of random
On Mon, Jan 10, 2022 at 2:13 PM Alex Deucher wrote:
>
> Sounds like something related to watermarks. That said, we haven't
> really touched the display code for DCE11 cards in quite a while. Can
> you provide your dmesg output?
I'm not seeing anything that would look interesting, but here's the
On Mon, Jan 10, 2022 at 5:11 PM Alex Deucher wrote:
>
> We are putting together a system to try and repro the issue. Does it
> happen with a single monitor or only with two?
Nope. With a single monitor everything seems to look fine. And when I
plug in the second monitor, it immediately starts ha
On Mon, Jan 10, 2022 at 5:21 PM Linus Torvalds
wrote:
>
> It also seems to depend a bit on the screen contents - or possibly on
> what else is going on. Hiding the browser window makes it happen less,
> I think. But I suspect that's about "less gpu activity" than
On Mon, Jan 10, 2022 at 5:21 PM Linus Torvalds
wrote:
>
> I'll see if I can bisect it at least partially.
It seems to be very reliable. I can see the flickering even at early
boot before gdb has started - the graphical screen where you type the
encrypted disk password at boot already
On Mon, Jan 10, 2022 at 6:22 PM Linus Torvalds
wrote:
>
> and I guess I'll do the few more bisections to pick out the exact one.
a896f870f8a5f23ec961d16baffd3fda1f8be57c is the first bad commit.
Attaching ther BISECT_LOG in case anybody cares.
I'll double-check to see if a re
On Mon, Jan 10, 2022 at 6:44 PM Linus Torvalds
wrote:
>
> I'll double-check to see if a revert fixes it at the top of my tree.
Yup. It reverts cleanly, and the end result builds and works fine, and
doesn't show the horrendous flickering.
I have done that revert, and will co
On Tue, Jan 11, 2022 at 7:38 AM Harry Wentland wrote:
>
> Attached is a v2 of the buggy patch that should get this right.
> If you have a chance to try it out let us know
I can confirm that I do not see the horribly flickering behavior with
this patch.
I didn't look at what the actual difference
On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie wrote:
>
> This is the main drm pull request for 4.8, I'm down with a cold at the moment
> so hopefully this isn't in too bad a state, I finished pulling stuff last
> week mostly (nouveau fixes just went in today), so only this message should
> be influe
On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä
wrote:
>
> I have a couple of pending PSR patches you may want to try as well,
> if i915.enable_psr=0 helps.
Yes. i915.enable_psr=0 seems to make the bad flickering go away.
I'll try your git trees out later, but what exactly changed with
regards t
On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä
wrote:
>
> So PSR seems more likely. The underruns might point at some watermark
> fail though :(
>
> I have a couple of pending PSR patches you may want to try as well,
> if i915.enable_psr=0 helps.
>
> First set is here:
> git://github.com/vsyrjala
On Mon, Aug 8, 2016 at 1:24 PM, Eric W. Biederman
wrote:
>
> Booting up v4.8-rc1 in qemu today I ran I ran into this beautiful oops.
>
> I am just about to head out the door on vacation until the end of the
> month so hopefully I am tossing out enough information to the right
> people.
>
> I have
Dave,
On Wed, May 8, 2019 at 8:28 PM Dave Airlie wrote:
>
> This is the main drm pull request for 5.2.
Thanks. I've merged it, but I got a couple of conflicts with fixes
(reverts) to mainline in the meantime.
The one to the i915 driver you seem to have applied again (after the
function was move
On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
>
> +# define roundup_64(x, y) (\
> +{ \
> + typeof(y) __y = y; \
> + typeof(x) __x = (x) + (__y - 1);\
>
On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
>
> I haven't yet tested this, but what about something like the following:
So that at least handles the constant case that the normal "roundup()"
case also handles.
At the same time, in the case you are talking about, I really do
suspect tha
On Thu, May 23, 2019 at 10:36 AM Steven Rostedt wrote:
>
> >
> > Of course, you probably want the usual "at least use 'int'" semantics,
> > in which case the "type" should be "(x)+0":
> >
> > #define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
> >
> > and the 8-bit and 16-bit cases wi
On Fri, Jan 18, 2019 at 12:43 PM Dave Airlie wrote:
>
> Going to be at LCA next week in Christchurch, but should be fine for
> normal pulls.
.. hey, me too.
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18
Pulled,
Linus
_
On Fri, Jun 7, 2019 at 12:24 AM Dave Airlie wrote:
>
> I sent this out earlier, but I forgot the subject, and then Ben asked
> about some nouveau firmware fixes.
Well, the first one at least had the address to pull from, and the diffstat.
The second one has the subject, and mentions nouveau, but
On Fri, Jun 7, 2019 at 10:20 AM Linus Torvalds
wrote:
>
> The second one has the subject, and mentions nouveau, but doesn't
> actually have the tag name or the expected diffstat and shortlog.
Hmm. I'm guessing you meant for me to pull the
'tags/drm-fixes-2019-06-0
On Thu, Jun 20, 2019 at 9:21 PM Dave Airlie wrote:
>
> Just catching up on the week since back from holidays, everything
> seems quite sane.
.. well, except for anongit.freedesktop.org itself, which seems very
sick indeed.
Does it work for you? I'm getting a connection reset, no data.
On Fri, Jun 21, 2019 at 10:06 AM Daniel Stone wrote:
>
> > Does it work for you? I'm getting a connection reset, no data.
>
> It is quite sick indeed; it's fallen down an NFS hole and is being
> restarted. Should be back in a few minutes.
Thanks, everything does indeed look good again now,
On Tue, Jul 9, 2019 at 12:24 PM Jason Gunthorpe wrote:
>
> I'm sending it early as it is now a dependency for several patches in
> mm's quilt.
.. but I waited to merge it until I had time to review it more
closely, because I expected the review to be painful.
I'm happy to say that I was overly p
On Mon, Jul 15, 2019 at 12:08 AM Dave Airlie wrote:
>
> VMware had some mm helpers go in via my tree (looking back I'm not
> sure Thomas really secured enough acks on these, but I'm going with it
> for now until I get push back).
Yeah, this is the kind of completely unacceptable stuff that I was
1 - 100 of 764 matches
Mail list logo
