From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758880AbcH3SKi (ORCPT ); Tue, 30 Aug 2016 14:10:38 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:37644 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758791AbcH3SKf (ORCPT ); Tue, 30 Aug 2016 14:10:35 -0400 MIME-Version: 1.0 In-Reply-To: References: <004c7dbe-2014-c691-29d1-7a45f3b73dfa@desertbit.com> <20160829160210.GA24451@localhost> <1cca943f-eab4-4054-4a13-31370d7ae057@desertbit.com> <20160829190737.GA4053@localhost> <20160829235403.GA14177@localhost> <1d1bfdc2-f23d-9816-e4e3-ae676105dc39@desertbit.com> <20160830130634.GA16426@localhost> <735da66c-aaf3-8c27-2d59-f62e8c85d3aa@desertbit.com> <43ce7a5b-8331-fec2-f598-afcb13ba3785@desertbit.com> From: Emil Velikov Date: Tue, 30 Aug 2016 19:10:31 +0100 Message-ID: Subject: Re: Kernel Freeze with American Megatrends BIOS To: Roland Singer Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , linux-acpi@vger.kernel.org, Ilia Mirkin Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30 August 2016 at 19:09, Emil Velikov wrote: > On 30 August 2016 at 18:37, Roland Singer wrote: >> I am running 4.7.2, but I also just tried the 4.8.0-rc4 mainline kernel. >> The result is the same. There is no difference if bbswitch of acpi_call >> is used. However I noticed following: >> >> 1. The nouveau driver is broken in both kernel version and is responsible >> for the freezes while gathering power state information with bbswitch. >> Sometimes while shutting the system down, everything except the LCD >> screen is switched off. This only happens with nouveau. >> I noticed following error log messages: >> > I second Ilia here. Using bbswitch in conjunction with any driver (be > that nouveau or the proprietary one) is a bad idea. > >> kernel: nouveau 0000:01:00.0: fb: 6144 MiB GDDR5 >> kernel: nouveau 0000:01:00.0: priv: HUB0: 10ecc0 ffffffff (1e40822c) >> kernel: nouveau 0000:01:00.0: DRM: VRAM: 6144 MiB >> kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB >> kernel: nouveau 0000:01:00.0: DRM: Pointer to TMDS table invalid >> kernel: nouveau 0000:01:00.0: DRM: DCB version 4.1 >> kernel: nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid >> >> 2. -> Boot with nouveau module loaded >> -> switch off the discrete GPU with bbswitch or acpi_call >> -> start X11 >> -> obtaining power state with bbswitch freezes the system >> -> or working with the system for some minutes freezes the system >> > (If Ilia's suggestions does not help) Confirm if the freeze is due > to/as the GPU is powered on or off. > >> 3. -> Boot with nouveau module blacklisted >> -> switch off the discrete GPU >> -> start X11 >> -> system immediately freezes >> > It's perfectly possible that the discrete GPU is set as boot one and X > goes angry since there's no driver/way to bring it up. > >> 4. -> Boot with nouveau module blacklisted >> -> switch off the discrete GPU >> -> start Wayland >> -> system runs - Note: I tried this for couple of days with 4.6 and 4.7 mainline >> and the system freezed randomly after some time. >> However I have to test if this is still present with 4.7.2 >> and 4.8 mainline. Right now it seams to be fine. >> -> running Xwayland (does not depend on the GPU power state) kills performance! >> the system freezes for several seconds... >> So working with Wayland is also no solution. >> >> My conclusion: >> >> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs. >> I would love to help here. >> >> 2. X11 is just broken and is not capable to start the graphical session >> if the nvidia GPU is not handled by any video driver (kernel module). >> Even forcing X11 to ignore the discrete GPU doesn't help. >> > Out of curiosity: how did you force X to ignore the device ? > >> Setting the command line arguments to: >> >> acpi_osi=! acpi_osi="Windows 2009" >> >> fixes the issues with X11 but other things break... >> What the hell is going on?! :/ >> > You can check if it's the boot_vga assumption with > [Sorry about that] ... cat /sys/class/drm/card*/device/{boot_vga,vendor} If the output changes them my assumption holds true. -Emil