Hi!
> > 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 very clear test-case?
>
> Even if you do
Hi!
> > > 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 graphics"
> >
> > Actually, maybe it's not graphics at all. R
Hi!
> > 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 graphics"
>
> Actually, maybe it's not graphics at all. Rafael just s
Hi!
> > 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 graphics"
>
> Actually, maybe it's not graphics at all. Rafael just s
Hi!
> > 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 graphics"
>
> Actually, maybe it's not graphics at all. Rafael just s
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At leas
Hi!
Extended Cc list. Should I attempt to prepare a patch?
Best regards,
Pavel
On Thu 2021-10-14 12:53:34, Pavel Machek wrote:
>
> CONFIG_INTEL_MEI_PXP:
>
> MEI Support for PXP Services on Intel platforms.
>
> Enables
CONFIG_INTEL_MEI_PXP:
MEI Support for PXP Services on Intel platforms.
Enables the ME FW services required for PXP support through
I915 display driver of Intel.
That's ... very useless help text. According to
https://www.phoronix.com/scan.php?page=news_item&px=Intel-PXP-Protected-Xe-Path
this
Hi!
> > I'm getting graphics problems with 5.13-rc:
> >
> > Debian 10.9, X, chromium and flightgear is in use. Things were more
> > stable than this with previous kernels.
> >
> > Any ideas?
>
> The error you are seeing:
>
> > [185300.784992] i915 :00:02.0: [drm] Resetting chip for stopped
Hi!
I'm getting graphics problems with 5.13-rc:
Debian 10.9, X, chromium and flightgear is in use. Things were more
stable than this with previous kernels.
Any ideas?
Best regards,
Pavel
[185233.329693] wlp3s0: deauthenticated fro
Hi!
> > Revert "drm/radeon: Fix reference count leaks caused by
> > pm_runtime_get_sync"
> > Revert "drm/radeon: fix multiple reference count leak"
> > Revert "drm/amdkfd: Fix reference count leaks."
>
> I didn't review these carefully, but from a quick look they all seem
> rather incon
Hi!
> > > > This is in -next, but I get same behaviour on 5.11; and no, udl does
> > >
> > > Thanks for reporting. We are in the process of fixing the issue. The
> > > latest
> > > patch is at [1].
> > >
> >
> > Thank you, that fixes the DMA issue, and I can use the udl.
> >
> > ...for a whil
Hi!
> > Thank you, that fixes the DMA issue, and I can use the udl.
> >
> > ...for a while. Then screensaver blanks laptop screen, udl screen
> > blanks too. Upon hitting a key, internal screen shows up, udl does
> > not.
> >
> > I try rerunning xrandr ... --auto, but could not recover it.
> >
Hi!
> >This is in -next, but I get same behaviour on 5.11; and no, udl does
>
> Thanks for reporting. We are in the process of fixing the issue. The latest
> patch is at [1].
>
Thank you, that fixes the DMA issue, and I can use the udl.
...for a while. Then screensaver blanks laptop screen, udl
Hi!
This is in -next, but I get same behaviour on 5.11; and no, udl does
not work, but monitor is detected:
pavel@amd:~/g/tui/crashled$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x
185
Hi!
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point to the same struct file. Since they depend on it for
> core
Hi!
> As the error capture will compress user buffers as directed to by the
> user, it can take an arbitrary amount of time and space. Break up the
> compression loops with a call to cond_resched(), that will allow other
> processes to schedule (avoiding the soft lockups) and also serve as a
> war
On Tue 2020-09-01 13:57:55, Harald Arnesen wrote:
> Still (rc3) doesn't work without the three reverts.
>
> I'm not sure how to proceed, I cannot capture any oops, and see nothing
> obvious in any logs.
I believe this is the place when you ask Linus for reverts...
Best regards,
I915_MAP_FORCE_WC);
> + map = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WB);
>
> on top of the previous patch. Faultinjection didn't turn up anything in
> eb_relocate_vma, so we need to dig deeper.
With this on top of other patches, it works.
Tested-by: Pav
Hi!
> >> It's a Thinkpad T520.
> >
> > Oh, so this is a 64-bit machine? Yeah, that patch to flush vmalloc
> > ranges won't make any difference on x86-64.
> >
> > Or are you for some reason running a 32-bit kernel on that thing? Have
> > you tried building a 64-bit one (user-space can be 32-bit,
t;
> Tested-by: Chris Wilson #x86-32
> Cc: # v5.8+
> Signed-off-by: Joerg Roedel
This seems to solve screen blinking problems on Thinkpad X60. (It
already survived few unison runs, which would usually kill it.).
Tested-by: Pavel Machek
Hi!
> > > The __apply_to_page_range() function is also used to change and/or
> > > allocate page-table pages in the vmalloc area of the address space.
> > > Make sure these changes get synchronized to other page-tables in the
> > > system by calling arch_sync_kernel_mappings() when necessary.
> >
Hi!
> > > The __apply_to_page_range() function is also used to change and/or
> > > allocate page-table pages in the vmalloc area of the address space.
> > > Make sure these changes get synchronized to other page-tables in the
> > > system by calling arch_sync_kernel_mappings() when necessary.
> >
On Thu 2020-08-20 09:16:18, Linus Torvalds wrote:
> On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote:
> >
> > Yes, it seems they make things work. (Chris asked for new patch to be
> > tested, so I am switching to his kernel, but it survived longer than
> > it usually
Hi!
> > I think there's been some discussion about reverting that change for
> > other reasons, but it's quite likely the culprit.
>
> Hmm. It reverts cleanly, but the end result doesn't work, because of
> other changes.
>
> Reverting all of
>
>763fedd6a216 ("drm/i915: Remove i915_gem_objec
On Tue 2020-08-18 18:59:27, Linus Torvalds wrote:
> On Tue, Aug 18, 2020 at 6:13 PM Dave Airlie wrote:
> >
> > I think there's been some discussion about reverting that change for
> > other reasons, but it's quite likely the culprit.
>
> Hmm. It reverts cleanly, but the end result doesn't work, b
Hi!
> > Yep, my machines are low on memory.
> >
> > But ... test did not work that well. I have dead X and blinking
> > screen. Machine still works reasonably well over ssh, so I guess
> > that's an improvement.
>
> > [ 7744.718473] BUG: unable to handle page fault for address: f8c0
> > [ 77
Hi!
> > > If we hit an error during construction of the reloc chain, we need to
> > > replace the chain into the next batch with the terminator so that upon
> > > flushing the relocations so far, we do not execute a hanging batch.
> >
> > Thanks for the patches. I assume this should fix problem f
Hi!
> If we hit an error during construction of the reloc chain, we need to
> replace the chain into the next batch with the terminator so that upon
> flushing the relocations so far, we do not execute a hanging batch.
Thanks for the patches. I assume this should fix problem from
"5.9-rc1: graphi
Hi!
> > I think there's been some discussion about reverting that change for
> > other reasons, but it's quite likely the culprit.
>
> Hmm. It reverts cleanly, but the end result doesn't work, because of
> other changes.
>
> Reverting all of
>
>763fedd6a216 ("drm/i915: Remove i915_gem_objec
Hi!
After about half an hour of uptime, screen starts blinking on thinkpad
x60 and machine becomes unusable.
I already reported this in -next, and now it is in mainline. It is
32-bit x86 system.
Pavel
Aug 17 17:36:04 amd ovpn-cas
Hi!
Next has been unusable for a while, but today I got dmesg.
Screen is blinking, machine is very unhappy, and ssh is slow/hangs,
but I got this:
This is recurring patern, usually machine dies like this within 30
minutes of boot.
[ 455.019838] perf: interrupt took too long (2509 > 2500), low
Hi!
I attempted to suspend x60, but it did not work well... Machine is too
messed up to pull more debug info from it :-(.
Best regards,
Pavel
[11645.369495] wlan0: RX AssocResp from 5c:f4:ab:10:d2:bb (capab=0x411 status=0
aid=2)
[1
On Mon 2020-06-22 10:13:13, Chris Wilson wrote:
> Quoting Pavel Machek (2020-06-22 09:52:59)
> > Hi!
> >
> > Linux duo 5.8.0-rc1+ #117 SMP PREEMPT Mon Jun 15 16:13:54 CEST 2020 x86_64
> > GNU/Linux
> >
> > [133747.719711] [ 17456] 0 17
Hi!
Linux duo 5.8.0-rc1+ #117 SMP PREEMPT Mon Jun 15 16:13:54 CEST 2020 x86_64
GNU/Linux
[133747.719711] [ 17456] 0 17456 4166 271655360
0 sshd
[133747.719718] [ 17466] 1000 17466 4166 289655360
0 sshd
[133747.719724] [
Hi!
On thinkpad X60 (x86-32): I got this: Had to reboot
Best regards,
Pavel
Jun 18 23:16:28 amd kernel: BUG: unable to handle page fault for
address: f860
Jun 18 23:16:28 amd kernel: #PF: supervisor write access in kernel
mode
Jun 1
Hi!
> > > Beyond the fix already submitted?
> >
> > I did not get that one, can I have a pointer?
>
> What's the status of this one?
I tried updating my kernel on April 3, that one did not work, but it
did not include 721017cf4bd8.
> I'm assuming the fix is commit 721017cf4bd8 ("drm/i915/gem: I
Hi!
> > > 7dc8f1143778a35b190f9413f228b3cf28f67f8d
> > >
> > > drm/i915/gem: Drop relocation slowpath
> > >
> > > Since the relocations are no longer performed under a global
> > > struct_mutex, or any other lock, that is also held by pagefault
> > > handlers,
> > > we can r
On Fri 2020-04-03 15:00:31, Pavel Machek wrote:
> Hi!
>
> 7dc8f1143778a35b190f9413f228b3cf28f67f8d
>
> drm/i915/gem: Drop relocation slowpath
>
> Since the relocations are no longer performed under a global
> struct_mutex, or any other lock, that i
Hi!
7dc8f1143778a35b190f9413f228b3cf28f67f8d
drm/i915/gem: Drop relocation slowpath
Since the relocations are no longer performed under a global
struct_mutex, or any other lock, that is also held by pagefault handlers,
we can relax and allow our fast path to take a fault. As
Hi!
> > > commit f365ab31efacb70bed1e821f7435626e0b2528a6
> > > Merge: 4646de87d325 59e7a8cc2dcf
> > > Author: Linus Torvalds
> > > Date: Wed Apr 1 15:24:20 2020 -0700
> > >
> > > Merge tag 'drm-next-2020-04-01' of
> > > git://anongit.freedesktop.org/drm/drm
>
>
> > Any ideas, besides th
Hi!
> > commit f365ab31efacb70bed1e821f7435626e0b2528a6
> > Merge: 4646de87d325 59e7a8cc2dcf
> > Author: Linus Torvalds
> > Date: Wed Apr 1 15:24:20 2020 -0700
> >
> > Merge tag 'drm-next-2020-04-01' of
> > git://anongit.freedesktop.org/drm/drm
> Any ideas, besides the b-word?
>
> Would
Hi!
> > > > Hardware is thinkpad x220. I had this crash few days ago. And today I
> > > > have similar-looking one, with slightly newer kernel. (Will post
> > > > as a follow-up).
> >
> > As part of quest for working system, I tried 5.7-rc0, based on
> >
> > Merge: 50a5de895dbe b4d8ddf8356d
> >
Hi!
> > > Hardware is thinkpad x220. I had this crash few days ago. And today I
> > > have similar-looking one, with slightly newer kernel. (Will post
> > > as a follow-up).
>
> As part of quest for working system, I tried 5.7-rc0, based on
>
> Merge: 50a5de895dbe b4d8ddf8356d
> Author: Linus To
Hi!
> > Hardware is thinkpad x220. I had this crash few days ago. And today I
> > have similar-looking one, with slightly newer kernel. (Will post
> > as a follow-up).
As part of quest for working system, I tried 5.7-rc0, based on
Merge: 50a5de895dbe b4d8ddf8356d
Author: Linus Torvalds
Date:
Hi!
Hardware is thinkpad x220. I had this crash few days ago. And today I
have similar-looking one, with slightly newer kernel. (Will post as a
follow-up).
Any idea what can be wrong?
Pavel
Hi!
I got an X hang and there seems to be something useful in dmesg... Any
ideas?
Pavel
[0.00] Linux version 5.5.0-rc1+ (pavel@amd) (gcc version 4.9.2 (Debian
4.9.2-10+deb8u2)) #73 SMP PREEMPT Fri Dec 13 00:46:17 C
On Tue 2019-10-22 17:12:06, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the drm_connector for the panel, that
> the userspace can then use to control and che
On Tue 2019-10-01 12:39:34, Jani Nikula wrote:
> On Mon, 30 Sep 2019, Pavel Machek wrote:
> > Hi!
> >
> > Thinkpad X220 should be new enough machine to talk DDC to the
> > monitors, right? And my monitor has DDC enable/disable in the menu, so
> > it should suppo
Hi!
> When 5.4-rc1 is booted on thinkpad X220 I get "snow" and other
> artefacts on digital output.
>
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
> Core Processor Family Integrated Graphics Controller (rev 09)
>
> It already snows when kernel is booting, snow continues
Hi!
When 5.4-rc1 is booted on thinkpad X220 I get "snow" and other
artefacts on digital output.
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09)
It already snows when kernel is booting, snow continues in X.
HDMI1 c
Hi!
Thinkpad X220 should be new enough machine to talk DDC to the
monitors, right? And my monitor has DDC enable/disable in the menu, so
it should support it, too...
But I don't have /dev/i2c* and did not figure out how to talk to the
monitor. Is the support there in the kernel? What do I need to
On Thu 2019-06-06 11:32:18, Jani Nikula wrote:
> On Mon, 03 Jun 2019, Pavel Machek wrote:
> > In recent kernels (5.2.0-rc1-next-20190522, 5.2-rc2) I'm getting
> > display corruption in X. Usually in terminals, but also in title bars
> > etc. Black areas with wh
Hi!
In recent kernels (5.2.0-rc1-next-20190522, 5.2-rc2) I'm getting
display corruption in X. Usually in terminals, but also in title bars
etc. Black areas with white lines in them, usually...
Same configuration worked properly in ... probably 4.19? Then I got
some graphics-crashes on X220 that p
Hi!
> > > So if you could please try drm-tip reproducing AND open a bug in Bugzilla.
> > > If you are unwilling to do that, it is very difficult to help you
> > > more.
> >
> > Website says I have to read and agree to two different pieces of
> > legalesee, and I'd need to keep track of yet anothe
Hi!
> > > > If you think it is useful, I can try to update my machine to
> > > > linux-next.
> > >
> > > linux-next is closer to drm-tip, so it's better. Do you have some
> > > specific reason for not wanting to run drm-tip (but linux-next is still
> > > ok)?
> >
> > I already have build/update
Hi!
> > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a
> > > > > > > genuine
> > > > > > > memory corruption (1 bit flipped):
> > > > > > >
> > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880
> > > > > > >
> > > > > > > Any extra information would be of
Hi!
Another day, another problem... but this one is different from the
previous hang, as machine survives.
Chromium was running with youtube video playing.
[31850.666274] [drm] GPU hangs can indicate a bug anywhere in the
entire gfx stack, including userspace.
[31850.666277] [drm] Please file a
On Sat 2018-12-08 12:13:46, Pavel Machek wrote:
> Hi!
>
> > > > > There's one similar for nouveau in Bugzilla, but it seems like a
> > > > > genuine
> > > > > memory corruption (1 bit flipped):
> > > > >
> > > >
Hi!
> > > > There's one similar for nouveau in Bugzilla, but it seems like a genuine
> > > > memory corruption (1 bit flipped):
> > > >
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880
> > > >
> > > > Any extra information would be of use :)
> > > >
> > > > Regards, Joonas
> > > >
>
Hi!
> > > There's one similar for nouveau in Bugzilla, but it seems like a genuine
> > > memory corruption (1 bit flipped):
> > >
> > > https://bugs.freedesktop.org/show_bug.cgi?id=84880
> > >
> > > Any extra information would be of use :)
> > >
> > > Regards, Joonas
> > >
> > > PS. Could you
Hi!
> > My machine locked hard (thinkpad x220). After reboot, I found this in
> > syslog:
> >
> > Sounds like memory corruption..? Does not sound like easy to debug.
>
> Were you doing something GPU intense when you experienced the hard hang?
>
> And if so, have you been able to hit the issue m
Hi!
My machine locked hard (thinkpad x220). After reboot, I found this in
syslog:
Sounds like memory corruption..? Does not sound like easy to debug.
...otoh, it still looks like an addres, so maybe it is "just" race in
GPU drivers?
Any ideas?
Hi!
> >> > Why would user of the machine want this to be something else than
> >> > 'OFF'?
> >> >
> >> > If kernel implements this, will it mean hardware vendors will have to
> >> > prevent user from updating kernel on machines they own?
> >> >
> >> > If this is merged, does it open kernel develop
On Tue 2017-12-05 11:45:38, Daniel Vetter wrote:
> On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote:
> > On Wed 2017-11-29 22:08:56, Sean Paul wrote:
> > > This patch adds a new optional connector property to allow userspace to
> > > enable
> > &g
On Wed 2017-11-29 22:08:56, Sean Paul wrote:
> This patch adds a new optional connector property to allow userspace to enable
> protection over the content it is displaying. This will typically be
> implemented
> by the driver using HDCP.
>
> The property is a tri-state with the following values:
On Mon 2017-01-23 10:39:27, Juergen Gross wrote:
> On 13/01/17 15:41, Juergen Gross wrote:
> > On 12/01/17 10:21, Chris Wilson wrote:
> >> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
> >>> On 11/01/17 18:08, Chris Wilson wrote:
> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Jue
On Mon 2017-03-06 12:23:41, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote:
> > On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> > > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > > > Hi!
> > > >
&
On Mon 2017-03-06 12:23:41, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote:
> > On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> > > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > > > Hi!
> > > >
&
Hi!
> > > > > > mplayer stopped working after a while. Dmesg says:
> > > > > >
> > > > > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
> > > >
> > > > Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to
> > > > try? Bisect will be slow and nasty :-(.
> > >
On Tue 2017-03-14 10:08:23, Thorsten Leemhuis wrote:
> On 06.03.2017 00:01, Pavel Machek wrote:
> >>> mplayer stopped working after a while. Dmesg says:
> >>>
> >>> [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
> > Now I&#
On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > mplayer stopped working after a while. Dmesg says:
> > > >
> > > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: regi
Hi!
> > mplayer stopped working after a while. Dmesg says:
> >
> > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to
try? Bisect will be slow and nasty :-(.
Hi!
mplayer stopped working after a while. Dmesg says:
[ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5
[ 3190.767227] [drm] GPU HANG: ecode 6:0:0xbb409fff, in chromium
[4597], reason: Hang on render ring, action: reset
Hi!
> [ Add some pm | i915 | x86 folks ]
>
> Hi,
>
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
>
> I cannot say which area touches the problem or if these are several
> independent problems.
>
On Fri 2016-11-18 11:14:16, Chris Wilson wrote:
> On Fri, Nov 18, 2016 at 12:02:56PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > With v4.9, if I maximize "nowcast -x" application, I get broken
> > display (as if someone split the window into rectangles an
Hi!
With v4.9, if I maximize "nowcast -x" application, I get broken
display (as if someone split the window into rectangles and shuffled
them a bit). Switching virtual desktops either fixes it or breaks it,
depending in how fast I switch. (Yes, strange).
pavel@amd:~$ lspci | grep VGA
00:02.0 VGA
Hi!
On Wed 2016-09-14 14:14:35, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Jani Nikula wrote:
> > On Wed, 14 Sep 2016, Pavel Machek wrote:
> >> For the "sometimes need xrandr after resume": I don't think I can
> >> bisect that. It only happens sometimes
On Wed 2016-09-14 10:38:18, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
> > Hi!
> >
> >> I have
> >>
> >> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> >> Integrated Graphics Controller (rev 03)
>
On Tue 2016-09-13 22:38:45, Martin Steigerwald wrote:
> Hi.
>
> Am Dienstag, 13. September 2016, 22:23:50 CEST schrieb Pavel Machek:
> > I have
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> > Integrated Graphics Controller (re
Hi!
> I have
>
> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> Integrated Graphics Controller (rev 03)
>
> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> powersave) and all w
Hi!
I have
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
in 10 resumes?) get in state where primary monitor (DVI) is dead (in
powersave) and all windows move to s
> On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote:
> >>Hi Alan,
> >>
> >>(Adding interested people to this thread)
> >>
> >>On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
> >I do feel that the importance of the mentioned bug is currently
> >underestimated. Can anyone here give a note, how
On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote:
> Hi Alan,
>
> (Adding interested people to this thread)
>
> On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
> > > > I do feel that the importance of the mentioned bug is currently
> > > > underestimated. Can anyone here give a note, how much curr
Hi!
> Could you try to apply the following patch [1], hopefully this fixes
> the issue for you.
>
> [1] https://patchwork.freedesktop.org/patch/89111/
I updated the kernel, applied the patch and yes, that helped.
Thanks!
P
On Sat 2016-05-28 12:12:06, Pavel Machek wrote:
> Hi!
>
> It looks like redshift stopped working. Even pretty crazy settings
> have no visible effect:
>
> pavel@amd:~$ redshift -O 1500 -g 6.6:6.6:6.6
> Using method `randr'.
> pavel@amd:~$ redshift -x
> Using meth
Hi!
It looks like redshift stopped working. Even pretty crazy settings
have no visible effect:
pavel@amd:~$ redshift -O 1500 -g 6.6:6.6:6.6
Using method `randr'.
pavel@amd:~$ redshift -x
Using method `randr'.
pavel@amd:~$ uname -a
Linux amd 4.6.0 #47 SMP Fri May 27 12:07:10 CEST 2016 x86_64 GNU/L
Hi!
> > I then ran a git bissect between v4.0 and v4.1 from Linus's tree and
> > found the "guilty" commit was
> >
> > commit 317b4e903636305cfe702ab3e5b3d68547a69e72
> > Author: Ben Widawsky
> > Date: Mon Mar 16 16:00:55 2015 +
> >
> > drm/i915: Extract context switch skip and add pd l
Hi!
> Reported-by: Jens Axboe
> Link: https://lkml.org/lkml/2015/11/12/621
> Cc: Jens Axboe
> Cc; "Rogozhkin, Dmitry V"
> Cc: Daniel Vetter
> Cc: Tvrtko Ursulin
> Cc: Eero Tamminen
> Cc: "Rantala, Valtteri"
> Cc: sta...@kernel.vger.org
> ---
> drivers/gpu/drm/i915/i915_gem.c | 28 +
> >>> commit e7d6f7d708290da1b7c92f533444b042c79412e0
> >>> Author: Dave Airlie
> >>> Date: Mon Dec 8 13:23:37 2014 +1000
> >>>
> >>> drm/i915: resume MST after reading back hw state
> >> Is there anything else what I can do ?
> >>
> >> Current kernels up to 4.2.3 and 4.3-rc3 (not harde
On Sun 2015-10-04 18:30:14, Toralf Förster wrote:
> On 08/04/2015 02:29 PM, Toralf Förster wrote:
> > On 08/02/2015 09:43 AM, Pavel Machek wrote:
> >> Any chance to bisect it?
> > Did it.
> >
> > FWIW: the mentioned commit was introduced between 3.18 and 3.19
On Wed 2015-07-29 15:54:00, Toralf Förster wrote:
> Undocking helps, and then I can dock again.
>
> This happens at a hardened 64 bit Gentoo with i915, but I think, it is
> not hardened related, or ?
Any chance to bisect it?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
On Wed 2015-07-01 13:53:31, Ville Syrjälä wrote:
> On Wed, Jul 01, 2015 at 11:51:27AM +0200, Pavel Machek wrote:
> > > > > - Embedded panels have a well defined shutdown sequence. We
> > don't
> >
> > > > > have
> > > > >
> > > - Embedded panels have a well defined shutdown sequence. We
don't
> > > have
> > > any good reason to not follow this, in fact for some panels the
> > > subsequent reinitialization could be problematic in case of a hard
> > > power-off. (Thanks to Jani for this info)
> >
> >
On Wed 2015-07-01 11:35:48, Jani Nikula wrote:
> On Tue, 30 Jun 2015, Pavel Machek wrote:
> > Hi!
> >
> >> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
> >> Author: Imre Deak
> >> Date: Thu Oct 23 19:23:26 2014 +0300
> >>
> >>
Hi!
> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
> Author: Imre Deak
> Date: Thu Oct 23 19:23:26 2014 +0300
>
> drm/i915: add poweroff_late handler
>
> introduced a regression on old platforms during hibernation. A workaround was
> added in
>
> commit ab3be73fa7b43f4c3648ce29b5fd649
Hi!
Debian 8 based system. X suddenly froze. Not quite reproducible, I'm afraid.
Pavel
[331445.592203] ftdi_sio 5-2:1.0: device disconnected
[331447.063345] r8169 :03:00.0 eth0: link up
[331447.930260] PM: resume of devices comp
Gcc warns that addr might be used uninitialized. It may not, but I see
why gcc gets confused.
Additionally, hiding code with side-effects inside WARN_ON() argument
seems uncool, so I moved it outside.
Signed-off-by: Pavel Machek
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu
On Mon 2014-07-07 10:39:08, Daniel Vetter wrote:
> On Fri, Jun 27, 2014 at 03:37:16PM +0200, Jiri Kosina wrote:
> > On Thu, 26 Jun 2014, Pavel Machek wrote:
> >
> > > Ok, so I have set up machines for ktest / autobisect, and found out that
> > > 3.16-rc1 no
complete non-sense since the WARNING
> backtraces in the references bugzilla are about
> gmch_pfit.lvds_border_bits mismatch, not at all about the dither bit.
> That one seems to work.
>
> Cc: Jiri Kosina
Acked-by: Pavel Machek
1 - 100 of 125 matches
Mail list logo
