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 Sat, Jul 20, 2013 at 5:22 PM, Rafael J. Wysocki wrote:
>
> I'm sending a separate pull request for this as it may be somewhat
> controversial.
Ugh. That's an understatement, and I hate the timing.
That said, it looks like it should be easy to revert if it causes
problems, and I guess it won't
On Wed, Jul 24, 2013 at 12:39 PM, Rafael J. Wysocki wrote:
>
> Well, there seems to be a number of people who'll be equally unhappy if I
> don't
> do that. Unfortunately for you, things work for them without that patch.
So I think we have to revert the behavior back, but I wonder if we
could ke
On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter wrote:
>
> I think a i915 module option should be doable, otoh people seem to have a
> viable workaround by setting a different acpi os version already.
At least the original claim was that if you set a non-windows8 acpi os
version, you hit other bug
On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote:
> So the bootloader is just as likely to step on things... what happens when/if
> it does?
This isn't a new problem. We've had this "firmware tables don't show
all devices" issue before.
The only odd thing about this one is how the quirk in
This one may have been going on for some time - I haven't updated the
old Intel Mac Mini in a while.
And by "not updated" I also mean that it's some really old user-space:
the machine is running F14, and cannot be updated to anything newer
without having to reinstall everything because of a stupid
On Fri, Aug 2, 2013 at 2:26 AM, Ville Syrjälä
wrote:
>
> Looks like this could happen when you go to DPMS_OFF. After we've turned
> off the the pipe, get_pipe_config() gives a mostly zeroed pipe_config
> (including pixel_multiplier), and then in the case of SDVO, we go and
> check it against the e
Testing running out of file descriptors shows a NULL pointer
dereference in i915_gem_alloc_object() because base.filp ends up being
NULL. So the line
mapping = file_inode(obj->base.filp)->i_mapping;
will cause an oops. The call chain is
SyS_ioctl ->
do_vfs_ioctl ->
drm_ioctl ->
i
On Sun, Jan 19, 2014 at 9:31 AM, Daniel Vetter wrote:
>
> This took much longer than I'll ever dare to admit, but I think I've
> stitched a testcase together for this and pushed it to our i915 test repo:
So I was testing a patch that limits one user to fewer than the global
system resource files,
Hmm. I just updated my machine to a i7-4770S (kept everything else the
same, just switched out motherboards), and now when my display goes to
sleep, it seems to never come back.
Any known issues with DVI on Haswell (it seems to show up as "HDMI1"
as the output, but it's a DVI cable)? I need to get
On Sat, Aug 31, 2013 at 4:02 PM, Linus Torvalds
wrote:
>
> Any known issues with DVI on Haswell (it seems to show up as "HDMI1"
> as the output, but it's a DVI cable)?
With a DP cable and the same monitor, the problem doesn't seem to
occur. So it does seem to someho
On Sun, Sep 1, 2013 at 11:54 PM, Daniel Vetter wrote:
> On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote:
>> Hmm. I just updated my machine to a i7-4770S (kept everything else the
>> same, just switched out motherboards), and now when my display goes to
>> sle
On Mon, Dec 26, 2011 at 5:02 PM, Keith Packard wrote:
> This leaves them enabled on IVB, but disables them on SNB as we've
> discovered (yet again) that there are hardware combinations that
> simply cannot run with them.
Oh well.
Applied,
Linus
___
On Wed, Jun 30, 2010 at 12:05 AM, Chris Wilson wrote:
>
> Reviewing the patch again, we no longer set the default gfpmask on the
> inode to contain NORETRY and instead add the NORETRY at the one spot in
> the code where we are trying to do a large allocation and our shrinker
> would be prevented f
On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
wrote:
>
> That commit changes the page cache allocation to use
>
> + mapping_gfp_mask (mapping) |
> +
On Thu, Jul 1, 2010 at 3:34 PM, M. Vefa Bicakci wrote:
>
> Based on my testing, I am happy to report that the change you suggest
> fixes the "memory corruption (segfaults) after thaw" issue for me.
> I can't thank you enough times for this.
Hey, goodie. And you're the one to be thanked - bisectin
On Thu, Jul 1, 2010 at 5:49 PM, Dave Airlie wrote:
>
> RECLAIMABLE added also seems fine, of course you can't have
> RECLAIMABLE and MOVABLE (I find this out when it oopses on boot).
Yes. They are both flags for the anti-fragmentation code, and I think
I'll leave the decision as to whether the i9
On Thu, Jul 1, 2010 at 5:37 PM, Greg KH wrote:
>
> This should go into .33 and .34-stable trees, right?
Yup. I added a "cc: stable" to the patch, and it's now commit
985b823b919 in my tree, you'll see it when I push it out along with
the other dri updates.
Linus
___
On Sat, Jul 17, 2010 at 11:58 AM, M. Vefa Bicakci
wrote:
>
> The kernel with d8e0902806c0bd2ccc4f6a267ff52565a3ec933b reverted
> was able to hibernate/thaw at least 40 times in one go, while
> the one with your fix applied was able to hibernate/thaw at most
> 17 times (in two separate trials) afte
On Sun, Jul 18, 2010 at 7:27 AM, M. Vefa Bicakci wrote:
>
> After hours of testing I came up with the following result: We need
> to have the __GFP_RECLAIMABLE flag in addition to GFP_HIGHUSER.
Thanks for the extensive testing, and I'm committing the one-liner to
add it, and cc'ing it to stable.
On Mon, Jan 3, 2011 at 10:12 AM, Knut Petersen
wrote:
>
> I tried 2.6.37-rc8-git2 with both patches applied.
I thought Chris meant "instead of", rather than "both". Chris?
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[ related, but independent, issue ]
On Mon, Jan 3, 2011 at 11:59 AM, Chris Wilson wrote:
>
>That function currently requires
> GMBUS to differentiate between a NAK and an IO error (bitbanging just
> returns EREMOTEIO regardless, iirc).
Hmm. That sounds like something
On Thu, Jan 20, 2011 at 9:29 AM, Knut Petersen
wrote:
> Kernel 2.6.38-rc1 and -git1 will lock my AOpen i915GMm-HFS
> at the end of KDE startup if automatic process group scheduling
> is actived in kernel config. A hard reset is necessary.
> Without automatic process group scheduling everything is
On Tue, Apr 5, 2011 at 3:30 AM, Chris Wilson wrote:
> On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler wrote:
>> On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg wrote:
>> > Unfortunately I get a blank screen with after boot:
>> > Nacked-by: Pekka Enberg
>
> But until you can tell me where it explo
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
On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter wrote:
>
> Fix this all by applying the same duct-tape as for the legacy setcrtc
> ioctl code and set crtc->primary->crtc properly.
Ack. Tests fine on the machine that showed issues for me.
I'll apply it manually directly to my tree, since I want to
On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter wrote:
>
> Fine with me. If you haven't pushed out yet can you maybe clarify the
> commit message?
Oh well. I already applied and tagged it, so it's what it is..
Linus
___
Intel-gfx mai
Sorry for the top post, I'm on the road..
In wondering if we couldn't just keep both the old an the new names and
have them both point at the same variable? Remove the description for the
old name, but keep it working?
Linus
On Jul 16, 2014 8:34 AM, "Amit Shah" wrote:
> This reverts commit
On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter wrote:
>
> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
Hmm. My laptop no longer resumes properly.
Or rather, I suspect it resumes, but the screen is black.
I will bisect, and I *will* revert if I find the offending comm
On Fri, Aug 8, 2014 at 12:19 PM, Linus Torvalds
wrote:
> On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter wrote:
>>
>> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
>
> Hmm. My laptop no longer resumes properly.
The problem seems to exist already wi
On Fri, Aug 8, 2014 at 12:37 PM, Linus Torvalds
wrote:
>
> The problem seems to exist already with just the plain drm pull from
> Dave. I thought I had tested that, but apparently not.
Still busy bisecting (and it's going into the i915 part of Dave's drm
pull, so the bisec
On Fri, Aug 8, 2014 at 10:30 AM, Linus Torvalds
wrote:
>
> This is a Sony Vaio Pro 11, so it's bog-standard intel graphics (Haswell ULT).
Got this while bisecting. I'm not sure it's related, the behavior was
a bit different from the other cases. So I'll try to contin
On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds
wrote:
>
> Got this while bisecting. I'm not sure it's related
It's not.
The actual bug was panel self refresh. It's still broken, and doesn't
work. So enabling it by default was a big mistake (commit
b6d547791fd3: &
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
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 doesn
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
So I just go the appended NULL pointer de-reference when trying to
look at a video from my GoPro.
The code disassembles to
0: 81 fb 00 04 00 00 cmp$0x400,%ebx
6: 41 89 07 mov%eax,(%r15)
9: 74 78 je 0x83
b: 48 8d 7c 24 18 lea0x18(%r
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
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 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 p
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 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: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 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 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 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 Sat, 18 Jan 2025 at 13:59, Guenter Roeck wrote:
>
> I am not sure what to do here. That kind of problem seems difficult
> to avoid, and I am sure we will hit it again elsewhere. Should I declare
> gcc 13.x off limits for parisc builds ?
No, I'm sure it can happen on other architectures too.
I
On Sat, 18 Jan 2025 at 09:49, Guenter Roeck wrote:
>
> No idea why the compiler would know that the values are invalid.
It's not that the compiler knows tat they are invalid, but I bet what
happens is in scale() (and possibly other places that do similar
checks), which does this:
WARN_ON
On Mon, 20 Jan 2025 at 10:55, Andy Shevchenko
wrote:
>
> Excuse me if I am missing something, but clamp() has a warning inside it,
> correct?
> Why do we need an additional warning on top of that?
Note: the warning in clamp() only finds compile-time obvious wrong uses.
It's really meant to noti
101 - 164 of 164 matches
Mail list logo
