| Bug ID | 101665 |
|---|---|
| Summary | lspci blocks forever with a GP107M |
| Product | xorg |
| Version | unspecified |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Driver/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | kenneth@whitecape.org |
| QA Contact | xorg-team@lists.x.org |
Hello, I have a Dell XPS 15 9560 with a GTX 1050 Mobile (GP107M) and an Intel Kaby= lake CPU. Using Kernel 4.11.3 on the Arch installer image, whenever I run 'lspc= i', it blocks indefinitely and never prints any output. After running lspci, dmesg contains: [ 54.819264] nouveau 0000:01:00.0: Refused to change power state, current= ly in D3 [ 54.879968] nouveau 0000:01:00.0: Refused to change power state, current= ly in D3 [ 54.879973] nouveau 0000:01:00.0: Refused to change power state, current= ly in D3 [ 54.879974] nouveau 0000:01:00.0: DRM: resuming object tree... Eventually the scheduler gets cranky about the hung process and starts spew= ing [ 245.385522] INFO: task lspci:576 blocked for more than 120 seconds. and a backtrace every 2 minutes. Blacklisting nouveau makes lspci work.
I believe including a full dmesg (from boot) would be helpful = to show what may be going wrong. Note that running with nouveau.runpm=3D0 will prevent the suspend from happ= ening. However that will, of course, cause the GPU to remain on. [I believe it will remain on without nouveau loading as well, but with this new PCIe PM stuff,= I'm not sure anymore.]
| What | Removed | Added |
|---|---|---|
| CC | peter@lekensteyn.nl |
With the "new PCIe PM stuff", if nouveau is not load= ed and something else enabled automatic runtime PM (via powertop, via TLP or manually by writing "auto" to /sys/bus/pci/devices/.../power/control) for the Nvidia = PCI devices, then indeed the problematic ACPI methods could be triggered. Kenneth, can you upload your acpidump? sudo pacman -S acpidump && sudo acpidump > acpidump.txt Most likely you are affected by https://bu= gzilla.kernel.org/show_bug.cgi?id=3D156341
this is because lspci reads the config file, which then trigge= rs a full GPU wake up, which is a silly thing to do in the first place. What we need is something like this in the kernel: https://github.com/karolherbst/linux/commit/cb918e4c9= 26990dfcfce92e1ecd905e0896de605 and then make use of those in userspace, so that we don't need to read conf= ig every time anymore.
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=3D100228 | |
| CC | rhyskidd@gmail.com |
| What | Removed | Added |
|---|---|---|
| CC | eurbah@free.fr |
I am trying to use 'nouveau' with GP107M [GeForce GTX 1050 Ti = Mobile]. With Linux Kernel 4.13.0-16 from Ubuntu 17.10 Artful, 'lspci' systematically makes immediately 1 CPU freeze. Therefore, I am testing Linux kernels from http://kernel.ubu= ntu.com/~kernel-ppa/mainline With Linux kernel 4.14.0-rc7, this issue does NOT show up : $ lspci -nn -v -s 1:0 01:00.0 3D controller [0302]: NVIDIA Corporation GP107M [GeForce GTX 1050 Ti Mobile] [10de:1c8c] (rev a1) Subsystem: Micro-Star International Co., Ltd. [MSI] GP107M [GeForce= GTX 1050 Ti Mobile] [1462:11c8] Flags: bus master, fast devsel, latency 0, IRQ 134 Memory at de000000 (32-bit, non-prefetchable) [size=3D16M] Memory at c0000000 (64-bit, prefetchable) [size=3D256M] Memory at d0000000 (64-bit, prefetchable) [size=3D32M] I/O ports at e000 [size=3D128] Expansion ROM at df000000 [disabled] [size=3D512K] Capabilities: <access denied> Kernel driver in use: nouveau Kernel modules: nvidiafb, nouveau With Linux kernel 4.14.0-rc8, 'lspci' systematically makes immediately the whole computer freeze. With Linux kernel 4.14.0 (released yesterday), 'lspci' systematically fails= to answer, and makes the whole computer freeze after some time. So, there is probably a regression. I have also reported this issue at ht= tps://bugs.launchpad.net/ubuntu/+source/linux/+bug/1729736
With following Linux kernels, 'lspci' systematically fails to = answer, and makes the whole machine immediately freeze : - 4.13.0-17 from Ubuntu 17.10 (Artful) - 4.14.1 from htt= p://kernel.ubuntu.com/~kernel-ppa/mainline
With Linux kernel 4.15.0-041500rc1 from http://kernel.ubu= ntu.com/~kernel-ppa/mainline, 'lspci' systematically fails to answer, and makes the whole machine freeze after some time.
With Linux kernel 4.15.0-041500rc2 from http://kernel.ubu= ntu.com/~kernel-ppa/mainline, 'lspci' systematically fails to answer, and makes the whole machine freeze after some time.
With Linux kernel 4.15.0-041500rc3 from http://kernel.ubu= ntu.com/~kernel-ppa/mainline, 'lspci' systematically fails to answer, and makes the whole machine freeze after some time. Besides, inside 'kern.log', I have detected following messages : nouveau 0000:01:00.0: DRM: BIT table 'A' not found nouveau 0000:01:00.0: DRM: BIT table 'L' not found nouveau 0000:01:00.0: DRM: Pointer to TMDS table invalid
@=C3=89tienne Could you please provide the information tha= t was asked in comment #1 and comment #2 of this bug repo= rt? Adding `nouveau.runpm=3D0` to the kernel command line should avoid the freeze but will prevent the NVIDIA card from being suspended. Looking at the bug report mentioned in comment #2, could you try booting with `acpi_osi=3D! acpi_osi=3D"Windows 2009"` and/or `acpi_rev_overrid= e=3D5` on the kernel command line (without `nouveau.runpm=3D0`)?
Created attachment 136105 [details]=
lspci for GP107M [GeForce GTX 1050 Ti Mobile]
Lot of thanks to Pierre Moreau for his suggestions of options in the kernel
command line :
- Adding just 'nouveau.runpm=3D0' prevents the whole machine to freeze, but
'nouveau' FAILS to manage an external display with resolution 3840 x 2160 at
60Hz through DisplayPort.
- Adding just 'acpi_rev_override=3D5' does NOT prevent the whole machine to
freeze.
- Adding just 'acpi_osi=3D! acpi_osi=3D"Windows 2009"' permits '=
lspci' to succeed,
and 'nouveau' to successfully manage an external display with resolution 38=
40 x
2160 at 60Hz through DisplayPort.
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=3D104621 |
With Linux kernel 4.16.0-041600rc5 from http://kernel.ubu= ntu.com/~kernel-ppa/mainline, 'lspci' systematically fails to answer, and makes the whole machine freeze after some time.
With Linux kernel 4.17.0-041700rc1 from http://kernel.ubu= ntu.com/~kernel-ppa/mainline, graphical login fails, and the machine is frozen.
With Linux kernel 4.17.0-041700rc1 from http://kernel.ubu= ntu.com/~kernel-ppa/mainline, I confirm that systematically : - Inside a Linux console, 'lspci' fails to answer, and makes the whole mac= hine immediately freeze. - Graphical login fails, and makes the whole machine immediately freeze.
I'm experiencing the same issue on an XPS 9560 with Ubuntu 18.= 04 (same symptoms, same dmesg output). Any new information required?
With Linux kernel 4.18.0-041800rc1 from http://kernel.ubu= ntu.com/~kernel-ppa/mainline : I tried to open a Linux console with Ctrl Alt F2, but did NOT succeed. Systematically, graphical login fails, and makes the whole machine immediat= ely freeze.
| What | Removed | Added |
|---|---|---|
| CC | andrey+freedesktop@psyduck.se |
Created attachment 143031 [details]<=
/span>
dmesg from thinkpad x1 extreme / GTX 1050 Ti on kernel 4.20 with hybrid
graphics
I may be blind but I haven't seen anyone attaching full dmesg output, sorry=
if
I missed it.
The laptop in question is Thinkpad X1 Extreme with NVIDIA Corporation GP107M
[GeForce GTX 1050 Ti Mobile] (rev a1). It has a BIOS setting to switch betw=
een
"Hybrid" and "Discrete only" graphics.=20
This dmesg output is from a boot with "Hybrid" graphics, where ru=
nning 'lspci'
hangs and causes the system fans to spin. X server hangs on start too (using
modesetting DDX)
Created attachment 143032 =
[details]
dmesg from thinkpad x1 extreme / GTX 1050 Ti on kernel 4.20 with discrete o=
nly
graphics
Not sure if that helps with the diagnostics, but on the same Thinkpad X1
Extreme laptop with "Discrete only" BIOS setting, lspci works fin=
e, X starts
and works, but there's a timeout logged by nouveau.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | NEW | RESOLVED |
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this = link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/iss= ues/358.