[PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer

On 12/01/16 at 04:00pm, Dave Young wrote: > On 11/30/16 at 03:25pm, Ville Syrjälä wrote: > > On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote: > > > On 11/24/16 at 10:53am, Jani Nikula wrote: > > > > On Thu, 24 Nov 2016, Dave Young wrote: > >

[PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer

On 11/30/16 at 03:25pm, Ville Syrjälä wrote: > On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote: > > On 11/24/16 at 10:53am, Jani Nikula wrote: > > > On Thu, 24 Nov 2016, Dave Young wrote: > > > > I see a lot of below warning: > > > > >

[PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer

On 11/24/16 at 10:53am, Jani Nikula wrote: > On Thu, 24 Nov 2016, Dave Young wrote: > > I see a lot of below warning: > > No, we must not hide this under the carpet. There's a bug at fdo about > this, and we need to fix it. It is not hiding it, just not repeating the wa

[PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer

link training It seems a known issue below: https://bugs.freedesktop.org/show_bug.cgi?id=97344 This is not to fix the real problem just use WARN_ON_ONCE is better for this kind of warnings instead of warn again and again. Signed-off-by: Dave Young --- drivers/gpu/drm/i915/intel_dp.c |2

[BUG] nouveau: softlockup in kexec kernel

Hi, nouveau does not works in kexec kernel on HP z420 workstation, Softlockup happens when the module init, see below full dmesg. BTW, the machine is using efi boot, I passed acpi_rsdp= in kernel cmdline. Also tried my efi runtime patches, result is same. But nouveau driver is happy with nouveau

WARNING: at drivers/gpu/drm/i915/i915_drv.c:440

On 06/01/2012 10:32 PM, Daniel Vetter wrote: > On Fri, Jun 01, 2012 at 02:21:25PM +0800, Dave Young wrote: >> Today I got a lot i915 warnings on a thinkpad t400, here is the something >> copied from syslog: >> [Known issue?] > > The gpu refuses to clear the write

Re: WARNING: at drivers/gpu/drm/i915/i915_drv.c:440

On 06/01/2012 10:32 PM, Daniel Vetter wrote: > On Fri, Jun 01, 2012 at 02:21:25PM +0800, Dave Young wrote: >> Today I got a lot i915 warnings on a thinkpad t400, here is the something >> copied from syslog: >> [Known issue?] > > The gpu refuses to clear the write

WARNING: at drivers/gpu/drm/i915/i915_drv.c:440

Today I got a lot i915 warnings on a thinkpad t400, here is the something copied from syslog: [Known issue?] Jun 1 13:31:13 localhost kernel: [15935.915986] [ cut here ] Jun 1 13:31:13 localhost kernel: [15935.916009] WARNING: at drivers/gpu/drm/i915/i915_drv.c:440 __g

WARNING: at drivers/gpu/drm/i915/i915_drv.c:440

Today I got a lot i915 warnings on a thinkpad t400, here is the something copied from syslog: [Known issue?] Jun 1 13:31:13 localhost kernel: [15935.915986] [ cut here ] Jun 1 13:31:13 localhost kernel: [15935.916009] WARNING: at drivers/gpu/drm/i915/i915_drv.c:440 __g

[PATCH] drm: avoid switching to text console if there is no panic timeout

On Wed, Oct 19, 2011 at 2:29 AM, Mandeep Singh Baines wrote: > Dave Young (hidave.darkstar at gmail.com) wrote: >> On Tue, Oct 18, 2011 at 10:19 AM, Dave Young >> wrote: >> > On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines > > chromium.org>

Re: [PATCH] drm: avoid switching to text console if there is no panic timeout

On Wed, Oct 19, 2011 at 2:29 AM, Mandeep Singh Baines wrote: > Dave Young (hidave.darks...@gmail.com) wrote: >> On Tue, Oct 18, 2011 at 10:19 AM, Dave Young >> wrote: >> > On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines >> > wrote: >> >> Fr

Re: [PATCH] drm: avoid switching to text console if there is no panic timeout

On Tue, Oct 18, 2011 at 10:19 AM, Dave Young wrote: > On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines > wrote: >> From: Hugh Dickins >> >> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if >> we're going to reboot immediately, t

Re: [PATCH] drm: avoid switching to text console if there is no panic timeout

On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines wrote: > From: Hugh Dickins > > Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if > we're going to reboot immediately, the user will not be able to see the > messages anyway, and messing with the video mode may display ar

[PATCH] drm: avoid switching to text console if there is no panic timeout

On Tue, Oct 18, 2011 at 10:19 AM, Dave Young wrote: > On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines > wrote: >> From: Hugh Dickins >> >> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if >> we're going to reboot immediately, t

[PATCH] drm: avoid switching to text console if there is no panic timeout

On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines wrote: > From: Hugh Dickins > > Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if > we're going to reboot immediately, the user will not be able to see the > messages anyway, and messing with the video mode may display a

Regression - Xorg start failed

On Sun, Feb 13, 2011 at 04:35:31PM -0800, Chris Wright wrote: > * Linus Torvalds (torvalds at linux-foundation.org) wrote: > > On Sat, Feb 12, 2011 at 11:53 PM, Dave Airlie wrote: > > > Probably should revert first, then work out what is crapping out > > > libpciaccess. > > > > Yeah, I'll revert

Re: Regression - Xorg start failed

On Sun, Feb 13, 2011 at 04:35:31PM -0800, Chris Wright wrote: > * Linus Torvalds (torva...@linux-foundation.org) wrote: > > On Sat, Feb 12, 2011 at 11:53 PM, Dave Airlie wrote: > > > Probably should revert first, then work out what is crapping out > > > libpciaccess. > > > > Yeah, I'll revert. T

Regression - Xorg start failed

Hi With kernel built from current linus's tree, I can not start xorg, it failed with: Backtrace: 0: X(xorg_backtrace+0x26) [0x4e8bb6] 1: X(xf86SigHandler+0x39) [0x489989] 2: /lib64/libc.so.6 [0x7f077a6b9f30] 3: /usr/lib64/libpciaccess.so.0(pci_device_get_bridge_buses+0xf1) [0x7f077c101fd1] 4: X(

Regression - Xorg start failed

Hi With kernel built from current linus's tree, I can not start xorg, it failed with: Backtrace: 0: X(xorg_backtrace+0x26) [0x4e8bb6] 1: X(xf86SigHandler+0x39) [0x489989] 2: /lib64/libc.so.6 [0x7f077a6b9f30] 3: /usr/lib64/libpciaccess.so.0(pci_device_get_bridge_buses+0xf1) [0x7f077c101fd1] 4: X(

intelfb refuses to load

On Sun, Dec 12, 2010 at 6:43 AM, Bruno Pr?mont wrote: > Hi, > > Looks like you are using the wrong intel driver. > > For intel modesetting you need > CONFIG_DRM=y > CONFIG_DRM_KMS_HELPER=y > # CONFIG_DRM_TDFX is not set > # CONFIG_DRM_R128 is not set > # CONFIG_DRM_RADEON is not set > # CONFIG_DRM

Re: intelfb refuses to load

On Sun, Dec 12, 2010 at 6:43 AM, Bruno Prémont wrote: > Hi, > > Looks like you are using the wrong intel driver. > > For intel modesetting you need > CONFIG_DRM=y > CONFIG_DRM_KMS_HELPER=y > # CONFIG_DRM_TDFX is not set > # CONFIG_DRM_R128 is not set > # CONFIG_DRM_RADEON is not set > # CONFIG_DRM

[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Wed, Oct 20, 2010 at 4:44 AM, Arnd Bergmann wrote: > On Tuesday 19 October 2010 22:29:12 Greg KH wrote: >> On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote: >> > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH: >> > > > So no need to clean it up for multiprocessor support.

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Wed, Oct 20, 2010 at 4:44 AM, Arnd Bergmann wrote: > On Tuesday 19 October 2010 22:29:12 Greg KH wrote: >> On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote: >> > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH: >> > > > So no need to clean it up for multiprocessor support.