On Wed, Nov 18, 2015 at 12:29 AM, Jani Nikula
wrote:
> On Tue, 17 Nov 2015, Daniel Vetter wrote:
>>
>> Imo revert. With all the QA awol fail we've suffered the past few
>> months we've become a bit too lax imo with reverting fast, and the
>> point of the split-out commit was to allow exactly that
On Thu, Nov 19, 2015 at 8:07 PM, Dave Airlie wrote:
>
> core: Atomic fixes and Atomic helper fixes
> i915: Revert for the backlight regression along with a bunch of fixes.
So I have no idea if the GPU updates are my problem, but my main
desktop machine has been hanging silently a few times lately
On Sun, Nov 29, 2015 at 11:33 PM, Daniel Vetter wrote:
>
> Yeah I just hunted down a test infrastructure failure on my Haswell the
> past few days with various loads and output configs. Seemed very happy.
> And not aware of anything else blowing up (bdw/skl would be less
> surprising).
So I'm cur
On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote:
>
> It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9
You didn't catch enough of the code line to decode the code, but it's
early enough in drm_crtc_index() (just five bytes in) that it's almost
certainly the very first dereference, so it's
On Thu, Jul 30, 2015 at 8:57 AM, Takashi Iwai wrote:
> On Thu, 30 Jul 2015 17:32:28 +0200,
> Theodore Ts'o wrote:
>>
>> BTW, is there any chance that I can suspend my laptop, and then move
>> it from my docking station at home (where I have a Dell 30" display)
>> to my docking station at work (whe
On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter
wrote:
>
> I delayed my -fixes pull a bit hoping that I could include a fix for the
> dp mst stuff but looks a bit more nasty than that. So just 3 other
> regression fixes, one 4.2 other two cc: stable.
Quick question: you can now reproduce the mst
On Fri, Jun 5, 2015 at 11:58 PM, Dave Airlie wrote:
>
> i915 has a bunch of fixes [..]
.. but nof ix for the regression that Stefan Lippers-Hollmann
reported? An oops in intel_modeset_update_connector_atomic_state() due
to commit 08d9bc920d46 ("drm/i915: Allocate connector state together
with the
On Fri, Jun 26, 2015 at 1:37 PM, Dave Airlie wrote:
>
> No generally Linus likes to do his own merges with hints from us.
>
> unless it's really tricky.
Yup. And this time all the merges were trivial. My merge ended up
differing from Dave's simply because of an ordering of statements that
could b
On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote:
>
> This is the main drm pull request for v4.2.
It seems to work ok for me, but it causes quite a few new warnings on
my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka
Haswell, aka 4th gen Intel Core i5)
Most of them are in
On Sat, Feb 28, 2015 at 11:27 PM, Linus Torvalds
wrote:
>
> I'll try to narrow it down at least a *bit* more, even if it's a
> painfully slow machine.
It was brought in by either
Merge tag 'topic/atomic-core-2015-01-05'
or
Merge tag 'topic/core-stuff-
On Sun, Mar 1, 2015 at 12:35 PM, Linus Torvalds
wrote:
>
> The compiles should be going faster now that I'm getting closer, so
> I'll have a tighter bisect soon. Knock wood.
Grr.
I found:
ccfc08655d5fd5076828f45fb09194c070f2f63a is the first bad commit
but that boot fa
On Sun, Mar 1, 2015 at 1:00 PM, Linus Torvalds
wrote:
>
> Back to the drawing board.
Ok, many hours later, but I found it.
The bisection was a disaster, having to work around other bugs in this
area, but it ended up getting "close enough" that I figured out what
On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter wrote:
>
> And can you please attach a bactrace of the WARN in your patch, just to
> double-check you blow up at the same spot?
So the dmesg I attached had a backtrace for the new WARN_ONCE() (in
addition to an unrelated(?) one from i915_gem_free_obje
So my el-cheapo UHD Dell monitor is unhappy with dmps, and just never
wakes up from it.
I work around it with just doing "xset -dpms" and it's not a big deal,
but I thought I'd report it anyway, since there are actual debug
messages, and maybe there's a better way to handle it. Does anybody
have a
On Tue, Jan 6, 2015 at 10:21 PM, Robert Morell wrote:
>
> FWIW, I've seen that exact symptom on some monitors when the +5V pin on
> the DVI or HDMI cable from the GPU isn't enabled (or isn't providing
> enough current). Some monitors power the i2c/edid/DDC logic from that
> +5V either exclusively
On Tue, Jan 6, 2015 at 11:32 PM, Daniel Vetter wrote:
>
> Yeah if the edid probe fails userspace will get a hotplug and
> autodisable the output. With a failsafe X session (just a dumb
> terminal) we can avoid that to check that dpms on itself would work or
> whether the edid probe fail here is ju
On Wed, Jan 7, 2015 at 9:51 AM, Daniel Vetter wrote:
>
> Not sure whether that'd be the same voltage rails, but
> i915.disable_power_wells=0 disable all the runtime pm we do (which
> does kick in for dpms off and shut down the entire display block and a
> bunch more)
I still get the "No HDMI (MHL
On Mon, Jan 26, 2015 at 6:06 PM, Dave Airlie wrote:
>
> are available in the git repository at:
>
> git://people.freedesktop.org/~airlied/linux drm-fixes
No they aren't, actually, because you've screwed up your repository.
It looks like you were using an alternates that has gone away:
remo
On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie wrote:
>
> Linus, this came up a while back I finally got some confirmation
> that it fixes those servers.
I'm certainly ok with this. which way should it go in? The users are:
- drivers/tty/vt/vt.c (Greg KH, "tty layer")
- drivers/video/console/*
On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman
wrote:
>
> I can take this through the tty tree, but can I put it in linux-next and
> wait for the 3.20 merge window to give people who might notice a
> slow-down a chance to object?
Yes. The problem only affects one (or a couple of) truly outra
On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte wrote:
>
> BUG: unable to handle kernel NULL pointer dereference at 0009
> IP: [] 0xbd3447bb
Ugh. Please enable KALLSYMS to get sane symbols.
But yes, "crtc_state->base.active" is at offset 9 from "crtc_state",
so it's pretty clearl
On Mon, Sep 7, 2015 at 9:56 PM, Dave Airlie wrote:
>
> i.e. 59 commits in a 5000 commit tree is likely not that bad, 59
> commits in a 20 commit tree would be bad.
I think it's about size of the commits. If it's 59 clean oneliner
fixes, I don't think it's a big deal. If it's 59 patches that add n
On Thu, Dec 10, 2015 at 10:58 PM, Dave Airlie wrote:
>
> So since Xmas is coming up and I've got an impending new arrival, I'm
> betting this merge window might get a bit haphazard. So I'd like
> people to start telling me now via git pull's what they'd like to get
> in.
So the rest of the world
On Wed, Dec 23, 2015 at 2:40 AM, Jani Nikula wrote:
>
> Hi Dave (and/or Linus, depending on the new arrival and eggnog
> schedules) -
I'll pull it directly. Dave just sent me his pending drm fixes, he may
or may not be around any more, it's already christmas eve down under.
Linus
On Wed, Dec 23, 2015 at 2:40 AM, Jani Nikula wrote:
>
>
> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-12-23
Btw, since you're already using tags, mind using *signed* tags
instead? It's just good housekeeping..
Linus
On Sun, Feb 15, 2015 at 10:43 PM, Dave Airlie wrote:
>
> This is the main drm pull, it has a shared branch with some alsa crossover
> but everything should be acked by relevant people.
Ugh. Your diffstat is crap, because you don't show the inexact renames
that are very abundant in the nouveau dri
On Fri, Feb 20, 2015 at 8:27 AM, Sumit Semwal
wrote:
>
> Could you please pull a few dma-buf changes for 3.20-rc1? Nothing
> fancy, minor cleanups.
No.
I pulled, and immediately unpulled again.
This is complete shit, and the compiler even tells you so:
drivers/staging/android/ion/ion.c: I
Hmm. I haven't updated the old Mac Mini I have in a *long* time, but
today I decided to try.
And it causes problems in drm.
I'm not sure how new these problems are, I think the previous kernel I
booted on this machine was 3.16. But I thought I'd better report them
as-is, because bisection on this
On Sat, Feb 28, 2015 at 9:40 PM, Linus Torvalds
wrote:
>
> I'm not sure how new these problems are, I think the previous kernel I
> booted on this machine was 3.16.
Hmm. 3.19 works fine, even if it ends up spewing
WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
drm_w
On Sat, Feb 28, 2015 at 10:08 PM, Linus Torvalds
wrote:
>
> I'll see how painful it is to bisect it,
Not surprisingly, it went right for the drm merge.
Commit 8c334ce8f0fe ("Merge branch 'timers-core-for-linus'..") is
good, while the next merge commit 796e1c
On Thu, Jun 6, 2013 at 2:14 PM, Dave Airlie wrote:
>
> 7 files changed, 32 insertions(+), 42 deletions(-)
That's not at all what I get (including shortlog). I got
29 files changed, 188 insertions(+), 68 deletions(-)
from a lot of commits you don't list.
Linus
Hmm. The odd Intel PCI resource mess is back.
Or maybe it never went away.
I get these when suspending. Things *work*, but it's really spamming
my logs a fair bit:
i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
pci_bus :01: Allocating resources
pci_bus :02
On Tue, Apr 21, 2015 at 12:24 AM, Chris Wilson
wrote:
>
> Though I am tempted to say we should impose the 256 byte limit for
> stable@
If the docs say 256, I'd suggest using that not just for stable, but
for anything. Maybe 511 bytes work everywhere and the docs are just
wrong. And maybe it does
On Tue, Apr 21, 2015 at 9:49 AM, Dmitry Torokhov
wrote:
> The hardware, according to the specs, is limited to 256 byte transfers,
> and current driver has no protections in case users attempt to do larger
> transfers. The code will just stomp over status register and mayhem
> ensues.
Thanks, look
On Thu, Apr 23, 2015 at 2:56 PM, Matthew Garrett
wrote:
> On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote:
>>
>> int pcibios_add_device(struct pci_dev *dev)
>> {
>> if (dev-is-default-vga-device) {
>> dev->rom = 0xC;
>> dev->romlen = 0x2;
>> }
>
> I don't know
On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o wrote:
>
> I've just tried pulling in your updated fixes-stuff, and it avoids the
> oops and allows external the monitor to work correctly.
Good. Have either of you tested the suspend/resume behavior? Is that fixed too?
> However
On Wed, Aug 12, 2015 at 10:46 AM, Alex Deucher wrote:
>
> Dave is on vacation at the moment, so please pull these fixes directly.
> Just a few minor things for 4.2:
So I've pulled this, but I'm noticing a very alarming pattern in your
pull requests: the commits are clearly generated just before t
On Wed, Aug 12, 2015 at 12:10 PM, Alex Deucher wrote:
>
> I always rebase my pull requests against Dave's drm-fixes tree before
> I send a pull request. Since he's out of town I rebased against your
> tree. I didn't realize that was not the preferred model. I thought
> it was preferred to fix u
On Wed, Aug 12, 2015 at 12:35 PM, Linus Torvalds
wrote:
>
> Generally, the preferred model is:
>
> - strive to base your development on a well-characterized base (for
> example, a previous release), and _stay_ on that base (ie don't get
> distracted by what other unrelat
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich
wrote:
>
> 3.10-rc7 doesn't compile for me
>
> rathamahata at piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage
> modules
> make[1]: Nothing to be done for `all'.
> make[1]: Nothing to be done for `relocs'.
> CHK include/generated
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich
wrote:
>> (and possibly the
>> mkregtable binary) and trying again might fix it.
>
> Removing mkregtable has indeed the compile issue for me. Thanks!
Ok, so something failed at an earlier build. That error is probably
long gone, though, since th
On Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich
wrote:
>
> There was overheating issue, that caused forced power off in the
> middle of the first compile.
Ok, then the thing is easily explained by simply the filesystem being
shut down in an incomplete state. Sounds like the mkregtable binary
h
On Thu, 19 Sept 2024 at 09:48, Dave Airlie wrote:
>
> There are some minor conflicts with your tree but none seemed too
> difficult to solve, let me know if there is any problems on your end.
Christ. One of them is due to you guys being horrible at merging.
Your tree had
drm/xe/gt: Remove d
On Fri, 25 Oct 2024 at 12:36, Helge Deller wrote:
>
> Do you want me to send a revert for this specific patch?
No, it's in now, more churn this time around just makes it worse. I
just don't want to see these kinds of non-fixes in the future.
Linus
On Fri, 25 Oct 2024 at 09:04, Helge Deller wrote:
>
> It's mostly about build warning fixes with cornercase CONFIG settings
> and one big patch which removes the now unused da8xx fbdev driver.
So I pulled this, but only later noticed that some of the Kconfig
"fixes" are anything but.
At least co
On Fri, 29 Nov 2024 at 14:59, Sasha Levin wrote:
>
> I should be able to reuse their config and just add debug info, no?
Sadly, no. Not unless you exactly match their compiler version. And it
looks like you don't, because the line numbers make no sense.
For example, this is the thing I would exp
On Thu, 28 Nov 2024 at 12:42, Dave Airlie wrote:
>
> Merge window fixes, mostly amdgpu and xe, with a few other minor ones,
> all looks fairly normal,
Hmm. I've pulled this, but do note the report by Sasha.
The
if (WARN_ON(!work->func))
return false;
from __flush_work()
On Sun, 8 Dec 2024 at 10:11, Martin Uecker wrote:
> >
> > A lot of the 'macro business' for min/max is avoiding unexpected
> > conversion of negative values to very large unsigned ones.
> > And no, -Wsign-compare is spectacularly useless.
>
> This is a different topic, but what would be needed her
On Thu, 5 Dec 2024 at 18:26, David Laight wrote:
>
> From: Vincent Mailhol
> > ACK. Would adding a suggested--by Linus tag solve your concern?
I'm genberally the one person who doesn't need any more credit ;)
> I actually suspect the first patches to change __is_constexpr() to
> use _Generic wer
On Sat, 7 Dec 2024 at 05:07, Martin Uecker wrote:
>
> VLA use *less* stack than a fixed size arrays with fixed bound.
Not really. You end up with tons of problems, not the least of which
is how to actually analyze the stack size. It also gets *very* nasty
to have code that declares the VLA size u
On Sat, 7 Dec 2024 at 11:51, Martin Uecker wrote:
>
> Am Samstag, dem 07.12.2024 um 10:19 -0800 schrieb Linus Torvalds:
> >
> > If there is one feature of C I would have liked it is "allow inline
> > functions and statement expressions with constant argument
On Sat, 7 Dec 2024 at 11:19, Martin Uecker wrote:
>
> But that all seem solvable issues on the compiler side.
You know, there was a whole *architecture* that was designed and
predicated on "it's all solvable on the compiler side".
That architecture was pure and utter *shit*.
Because no, it's no
On Sat, 7 Dec 2024 at 15:52, Martin Uecker wrote:
>
> Can you point me to some horror stories?
So the main issues tended to be about various static verification tools.
Ranging from things like the stackleak plugin for gcc, where handling
VLA's and alloca() (which are pretty much the same thing w
On Sat, 7 Dec 2024 at 04:24, Vincent Mailhol wrote:
>
> > No good - expands everything twice.
>
> And? __is_const_zero() does not evaluate its arguments, so no side effect:
No, the problem is literally the expansion.
Double expansion of these fundamental helpers gets exponential,
because they ar
On Fri, 7 Feb 2025 at 10:02, Hector Martin wrote:
>
> Meanwhile, for better or worse, much of Linux infra *is* centralized -
> for example, the mailing lists themselves, and a lot of the Git hosting.
The mailing lists are mostly on kernel.org, but the git hosting most
certainly is not centralized
On Thu, 6 Feb 2025 at 01:19, Hector Martin wrote:
>
> If shaming on social media does not work, then tell me what does,
> because I'm out of ideas.
How about you accept the fact that maybe the problem is you.
You think you know better. But the current process works.
It has problems, but problem
On Sun, 2 Feb 2025 at 12:15, Dave Airlie wrote:
>
> Currently FW_CACHE is an optional feature (that distros may or may not
> configure off), where we will cache loaded firmwares to avoid problems
> over suspend/resume (and speed up resume).
>
> I've just discovered a problem in nouveau's suspend c
On Thu, 12 Dec 2024 at 21:47, Yafang Shao wrote:
>
> Since task->comm is guaranteed to be NUL-terminated, we can print it
> directly without the need to copy it into a separate buffer.
So i think we should do the "without copying into a separate buffer"
part of this series, but I do think we shou
On Fri, 6 Dec 2024 at 10:31, Vincent Mailhol wrote:
>
> > causes issues when 'x' is not an integer expression (think
> > "is_const(NULL)" or "is_const(1 == 2)".
>
> But 1 == 2 already has an integer type as proven by:
Yeah, I was confused about exactly what triggers that odd
'-Wint-in-bool-contex
On Fri, 6 Dec 2024 at 10:52, Linus Torvalds
wrote:
>
> This may be a case of "we just need to disable that incorrect compiler
> warning". Or does anybody see a workaround?
Hmm. The "== 0" thing does work, but as mentioned, that causes (more
valid, imho) warnings
On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
>
> I'm missing the compiler version and options to generate the error.
Just -Wall with most recent gcc versions seems to do it. At least I
can repro it with gcc-14.2.1 and something silly like this:
$ cat t.c
int fn(int a) { return (a<<2)?1:2
On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
>
> I'm pushing this soon to drm-intel-next, unless Linus want to take
> this one directly to his tree
Let's just go through the proper channels and go through the drm tree.
Unless I've issed something, I think this is only an active issue on
par
On Thu, 23 Jan 2025 at 05:56, Vignesh Raman wrote:
>
> Documentation/ci/gitlab-ci/images/drm-vkms.png | Bin 0 -> 73810 bytes
> .../ci/gitlab-ci/images/job-matrix.png | Bin 0 -> 2 bytes
> .../ci/gitlab-ci/images/new-project-runner.png | Bin 0 -> 607737 bytes
> .../ci/gitlab-ci/image
Side note: I think you do something while editing or
cutting-and-pasting that loses indentation.
I sometimes have to guess at what the intended grouping is.
In this case, notice the "More catalog fixes" entry for the msm driver.
I *think* it refers to all the following bullet points up until the
On Thu, 27 Mar 2025 at 19:53, Dave Airlie wrote:
>
> This is the main drm pull request for 6.15. Bit late, but my wife was
> away getting a PhD and kids took over my writing summaries time, and
> fd.o was offline last week which slowed me down a small bit.
Grr. I did the pull, resolved the (trivi
701 - 765 of 765 matches
Mail list logo
