similar to: 3.8-rc2: EFI framebuffer lock inversion...

Dropping Tegra ML, it's not the place where Nouveau mails should go. Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best. Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov: > New -rc1, so let the stabilization games begin. > > I see the following on rc1, let me know if you need more info. > > > [ 0.633617]

On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: > Backlights controlled by i915.ko and only associated with its connectors > and also only associated with the intel_drmfb fbcon, controlled by > i915.ko. In this situation, we already handle adjusting the backlight > when the fbcon is blanked/unblanked and do not require backlight trying > to do the same. > >

On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote: > On Tue, 12 Jul 2016, Daniel Vetter <daniel at ffwll.ch> wrote: > > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: > >> Backlights controlled by i915.ko and only associated with its connectors > >> and also only associated with the intel_drmfb fbcon, controlled by > >> i915.ko. In

Backlights controlled by i915.ko and only associated with its connectors and also only associated with the intel_drmfb fbcon, controlled by i915.ko. In this situation, we already handle adjusting the backlight when the fbcon is blanked/unblanked and do not require backlight trying to do the same. Attempting to register with the fbdev as a client causes lockdep to warn about a dependency cycle: [

On Tue, 12 Jul 2016, Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: >> Backlights controlled by i915.ko and only associated with its connectors >> and also only associated with the intel_drmfb fbcon, controlled by >> i915.ko. In this situation, we already handle adjusting the backlight >> when the fbcon is

The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called while nouveau was runtime suspended, a deadlock would occur due to nouveau_fbcon_set_suspend also trying to obtain console_lock(). Fix this by delaying the drm_fb_helper_set_suspend call. Based on the i915 code (which was done for performance reasons though). Cc: Chris Wilson <chris at chris-wilson.co.uk> Cc: Daniel

From: Robin Murphy <robin.murphy at arm.com> This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50. There is apparently something amiss with the way the TTM code handles DMA buffers, which the above commit was attempting to work around for arm64 systems with non-coherent PCI. Unfortunately, this completely breaks systems *with* coherent PCI (which appear to be the majority).

My old machine started getting a bit flaky, so I have kicked it off my desk, but still wanted to get some nouveau bugs fixed on it. (In fact it's easier now that I can reboot it more easily.) So I put a spare old hard drive on it and rebuilt it, but I'm having a heck of a time getting it working. Whenever it tries to load the nouveau module, it blows up. What's funny is that it

This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50. There is apparently something amiss with the way the TTM code handles DMA buffers, which the above commit was attempting to work around for arm64 systems with non-coherent PCI. Unfortunately, this completely breaks systems *with* coherent PCI (which appear to be the majority). Booting a plain arm64 defconfig + CONFIG_DRM +

Dear CentOS project's member I hope to decide the following problem with your knowledge. 1.I installed the CentOS6.2 into the DELL PC(https://www.dell.com/support/manuals/jp/ja/jpbsd1/latitude-e7440-ultrabook/late7440om-v3/specifications?guid=guid-247916a5-f1d3-44b2-82b7-f14374bb9a73&lang=en-us) with bootable usb created with CentOS-6.2-x86_64-minimal.iso. after that.I started the

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-1 Severity: normal Hello, I've this message in dmesg that I can't understand: [ 4.032472] ------------[ cut here ]------------ [ 4.032521] WARNING: at /build/buildd-linux-2.6_2.6.32-26-amd64-KkHF2p/linux-2.6-2.6.32/debian/build/source_amd64_xen/mm/page_alloc.c:1833 __alloc_pages_nodemask+0x177/0x5f5() [ 4.032590] Hardware name:

Hi, While trying out v4.8-rc2 on Juno r2 (arm64), I ran into the following crash when probing the nvidia graphics card attached to the PCIe slot. So I tried rc1 and got the same crash. The card probes without any errors on v4.7. Anybody familiear with the recent changes knows what might have led to the below crashlog? Thanks, Punit ------------->8------------- [ 2.996678] [drm]

On 06/06/16 08:11, Alexandre Courbot wrote: > From: Robin Murphy <robin.murphy at arm.com> > > This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50. > > There is apparently something amiss with the way the TTM code handles > DMA buffers, which the above commit was attempting to work around for > arm64 systems with non-coherent PCI. Unfortunately, this completely

> -----Original Messages----- > From: "Steven Tardy" <sjt5atra at gmail.com> > Sent Time: 2019-04-28 13:02:18 (Sunday) > To: "CentOS mailing list" <centos at centos.org> > Cc: > Subject: Re: [CentOS] Who is responsible to load NIC driver when boot up > > On Sat, Apr 27, 2019 at 11:44 PM wuzhouhui <wuzhouhui14 at mails.ucas.ac.cn> >

I''m testing xen 3.4 on my servers, and I''m having problem with controller driver, he can''t load itself properly so the system isn''t booting. The system is debian 5.0 with kernel 2.6.26-2-xen from distribution and 2.6.29-5 compiled, the problem occure with both kernels ouput from debian 5.0/kernel 2.6.26-2-xen/xen-3.4.1-rc2 4.306723] PNP: No PS/2

I have a crash on the current stable kernel. Here is the trace from dmesg:- ---------------------------------------------------------- CPU: 0 PID: 682 Comm: modprobe Not tainted 3.13.0-rc3_exact-293199-g374b105 #379 Hardware name: / , BIOS GB85010A.86A.0063.P14.0107182015 07/18/2001 task: ef5b1a80 ti: ef5d8000 task.ti: ef5d8000 EIP: 0060:[<f0cfe995>] EFLAGS:

Hello everyone, the current git HEAD of Linus Torvalds tree breaks Nouveau on my Mac Mini Model 2010. I get variation of the following kernel panic when booting. (gateway) [~] nc -u -l -p 6666 [ 3.796018] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.796100] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 3.796304] ata1.00: ATA-7: INTEL SSDSA2M160G2GC, 2CV102HA, max

https://bugs.freedesktop.org/show_bug.cgi?id=56461 Priority: medium Bug ID: 56461 Assignee: nouveau at lists.freedesktop.org Summary: NV11 black screen & kernel hang on loading nouveaufb QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: chris at