Re: [Nouveau] Thinkpad P17 gen 2 kernel 6.4 and 6.6 lack of support for nvidia GA104GLM [RTX A5000 Mobile] and missing module firmware
On Sat, Dec 02, 2023 at 06:08:01PM +, Timur Tabi wrote: > On Sat, 2023-12-02 at 09:13 -0800, Marc MERLIN wrote: > > [ 3.184525] nouveau: unknown parameter 'modset' ignored > > For starters, you misspelled "modeset" That was a previous boot in dmesg where I failed to turn off the module, but I was mostly interested in showing the errors of all the firmware missing and nouveau failing to start, which those logs do show. Separely, both 6.4 and 6.6 are hanging after a few hours of runtime with networking dying or other issues that require reboot See below 6.4: > [55647.774842] vgaarb: client 0xc24cb19e called 'target' > [55647.774852] vgaarb: PCI::00:02.0 ==> :00:02.0 pdev bfa35d85 > [55647.774854] vgaarb: vgadev 8ea0fc7d > [55825.318992] INFO: task NetworkManager:3372 blocked for more than 120 > seconds. > [55825.318999] Tainted: G U OE > 6.4.9-amd64-preempt-sysrq-20220227 #2 > [55825.319000] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [55825.319002] task:NetworkManager state:D stack:0 pid:3372 ppid:1 > flags:0x0002 > [55825.319005] Call Trace: > [55825.319006] > [55825.319009] __schedule+0xba5/0xc17 > [55825.319015] schedule+0x95/0xce > [55825.319017] schedule_preempt_disabled+0x15/0x22 > [55825.319020] __mutex_lock.constprop.0+0x18b/0x291 > [55825.319025] nl80211_prepare_wdev_dump+0x8b/0x19f [cfg80211 > d0c23c84d531afea8d4a2711c5c3e691cbb9587f] > [55825.319065] nl80211_dump_station+0x49/0x1d0 [cfg80211 > d0c23c84d531afea8d4a2711c5c3e691cbb9587f] > [55825.319091] ? __mod_lruvec_page_state+0x4c/0x86 > [55825.319093] ? mod_lruvec_page_state.constprop.0+0x1c/0x2e > [55825.319096] ? __kmalloc_large_node+0xd5/0xfb > [55825.319099] ? __kmalloc_node_track_caller+0x5a/0xad > [55825.319101] ? kmalloc_reserve+0xa7/0xe2 > [55825.319104] ? __alloc_skb+0xe9/0x148 > [55825.319106] netlink_dump+0x143/0x2b2 > [55825.319109] __netlink_dump_start+0x125/0x177 > [55825.319111] genl_family_rcv_msg_dumpit+0xf1/0x110 > [55825.319114] ? poll_freewait+0x72/0x91 > [55825.319117] ? __pfx_genl_start+0x40/0x40 > [55825.319119] ? __pfx_nl80211_dump_station+0x40/0x40 [cfg80211 > d0c23c84d531afea8d4a2711c5c3e691cbb9587f] > [55825.319143] ? __pfx_genl_parallel_done+0x40/0x40 > [55825.319146] genl_rcv_msg+0x189/0x1e2 > [55825.319148] ? __pfx_nl80211_dump_station+0x40/0x40 [cfg80211 > d0c23c84d531afea8d4a2711c5c3e691cbb9587f] > [55825.319172] ? __pfx_genl_rcv_msg+0x40/0x40 > [55825.319173] netlink_rcv_skb+0x89/0xe3 > [55825.319176] genl_rcv+0x24/0x31 > [55825.319178] netlink_unicast+0x10e/0x1ae > [55825.319180] netlink_sendmsg+0x321/0x361 > [55825.319182] sock_sendmsg_nosec+0x35/0x64 > [55825.319186] sys_sendmsg+0x13e/0x1ef > [55825.319188] ___sys_sendmsg+0x76/0xb3 > [55825.319190] ? __fget_light+0x41/0x50 > [55825.319193] ? do_epoll_wait+0x49b/0x4d4 > [55825.319196] ? __pfx_pollwake+0x40/0x40 > [55825.319198] ? __rseq_handle_notify_resume+0x2a0/0x4bd > [55825.319200] ? __fget+0x38/0x47 > [55825.319202] __sys_sendmsg+0x60/0x97 > [55825.319204] do_syscall_64+0x7e/0xa7 > [55825.319208] ? syscall_exit_to_user_mode+0x18/0x27 > [55825.319210] ? __task_pid_nr_ns+0x5f/0x6d > [55825.319213] ? syscall_exit_to_user_mode+0x18/0x27 > [55825.319214] ? do_syscall_64+0x9d/0xa7 > [55825.319216] ? do_syscall_64+0x9d/0xa7 > [55825.319218] ? do_syscall_64+0x9d/0xa7 > [55825.319220] ? do_syscall_64+0x9d/0xa7 > [55825.319222] entry_SYSCALL_64_after_hwframe+0x77/0xe1 > [55825.319224] RIP: 0033:0x7f1fdc79e9bd > [55825.319226] RSP: 002b:7ffeb6460900 EFLAGS: 0293 ORIG_RAX: > 002e > [55825.319228] RAX: ffda RBX: 55e0a9ce1d90 RCX: > 7f1fdc79e9bd > [55825.319229] RDX: RSI: 7ffeb6460950 RDI: > 000b > [55825.319230] RBP: 7ffeb6460950 R08: R09: > 0300 > [55825.319231] R10: R11: 0293 R12: > 7ffeb6460a30 > [55825.319232] R13: 7f1fd0038690 R14: 7ffeb6460c60 R15: > 55e0aa210400 > [55825.319234] 6.6.3: [ 443.613095] BTRFS info (device dm-2): scrub: started on devid 1 [ 484.778344] INFO: task kworker/2:1:106 blocked for more than 120 seconds. [ 484.778352] Tainted: G U 6.6.3-amd64-preempt-sysrq-20220227 #4 [ 484.778353] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 484.778354] task:kworker/2:1 state:D stack:0 pid:106 ppid:2 flags:0x4000 [ 484.778358] Workqueue: ipv6_addrconf addrconf_verify_work [ 484.778365] Call Trace: [ 484.778367] [ 484.778369] __schedule+0xba0/0xc05 [ 484.778373]
[Nouveau] Thinkpad P17 gen 2 kernel 6.4 and 6.6 lack of support for nvidia GA104GLM [RTX A5000 Mobile] and missing module firmware
Howdy, I'm trying a Thnkpad P17 gen2, the last thinkpad that still comes in 17" 4K (newer ones are 16" only, so I'm looking for other worthwhile linux laptops with 17" or bigger LCD that also does 4K, the alienware I saw was 18" but not 4K) Unfortunately I seem to need the nouveau driver to turn off the nvidia chip I don't plan on using (intel graphics is fine for me), and bios only allows 'bybrid' or nvidia only) On my P73, nouveau never really worked in the 3 years I've had it, but it could at least turn off the nvidia chip. On P17gen2 it does not seem to be able to do so. Firmware is missing even from the latest firmware-linux-nonfree or from upstream git https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git sauron:~# update-initramfs -v -c -k `uname -r` 2>&1 |grep W: W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/desc.bin for module nouveau During boot, the nvidia module hangs for 2mn and fails to do any work, including being able to turn off the nvidia chip (which it could do on P73 without otherwise ever being able to use that chip for proper display). I want to turn off the nvidia chip so that I can get multi hour runtime on batteries without some useless chip that is using power for no reason. sauron:~# lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Tiger Lake-H GT1 [UHD Graphics] (rev 01) 01:00.0 VGA compatible controller: NVIDIA Corporation GA104GLM [RTX A5000 Mobile] (rev a1) Boot looks like this: [0.210932] Kernel command line: BOOT_IMAGE=/vmlinuz-6.6.3-amd64-preempt-sysrq-20220227 root=/dev/mapper/cryptroot ro rootflags=subvol=root cryptopts=source=/dev/nvme0n1p7,keyscript=/sbin/cryptgetpw usbcore.autosuspend=1 pcie_aspm=force resume=/dev/dm-1 thinkpad-acpi.brightness_enable=1 acpi_backlight=native nouveau.modset=0 systemd.unified_cgroup_hierarchy=0 [3.184525] nouveau: unknown parameter 'modset' ignored [3.184800] nouveau: detected PR support, will not use DSM [3.184813] nouveau :01:00.0: vgaarb: pci_notify [3.184816] nouveau :01:00.0:
Re: [Nouveau] 6.2 still cannot get hdmi display out on Thinkpad P73 Quadro RTX 4000 Mobile/TU104
To the noueau devs: Is there an appropriate list/forum to get support for nouveau, or is this the list? The nvidia support forums seem to be for the binary nvidia driver which I'm not running. On Mon, May 08, 2023 at 05:38:38PM -0500, Steven Kucharzyk wrote: > I understand parts of your motivation in how you want to deal with > Nvidia. Without knowing what you have or have not done in your > past efforts and what those results were, my diagnostic approach would > start by verifying that the HW (chip) is not damaged by previous > experiments or from the get go. Here's a link to a python gpu test app. > Hope that helps. > https://www.geeks3d.com/gputest/download/ Sure, although for now, it of course runs on my main GPU, the intel one, so that does not help much. > First things, is to prove the chip works, then that target delivery > (cables etc.) works then reduce down to your desired working setup. > Lastly and I'm sure that you are aware that Nouveau is AMD centric ... > opensuse is darn right hostile while redhat(ibm) not so much so. > Lastly, Nvidia (xCFG) manual highlights numerous optional cmds for fine > grain control that's not in the gui depending on what you're going for. > ( know thy enemy) I already know the chip and cable work (although I did swap cables), as per my original report with debug info, the screen comes on and I see a mouse cursor but nothing else. It mirrors the cursor on the HDMI output connected to the nvidia chip from my main display on intel, but it does not mirror the framebuffer. I realize that few people likely have my setup (dual chip laptop), I got it to work with nouveau on my with P70 with an older nvidia chip, at this point I would *so* love for anyone working on this project to tell me whether it's supposed to work or whether it has never been tested/confirmed to work yet. Of if I'm spamming the wrong forum, I will happily move a better place. Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08
Re: [Nouveau] 6.2 still cannot get hdmi display out on Thinkpad P73 Quadro RTX 4000 Mobile/TU104
On Fri, May 05, 2023 at 01:56:50PM -0500, Steven Kucharzyk wrote: > Nvidia does great support (on-line chat) don't remember if you need to > sign-up for free account or not but I say first hand that your talking > with an engineer who will answer *any* type question. I've been buying > Nvidia for twenty yrs. or more and have actually been to the site. > They're very customer centric, so much so that on saturdays they (did) > would give kids the opportunity to come in and play with experimental > setups. Even with Nouveau running you're going to need some parts of their > drivers. >From what I understand, nvidia supports their out of tree binary drivers. I'm not really interested in using them for a variety of reasons including the fact that I have no use for the chip on my laptop (I was forced to buy it) and I only need to power on the chip when I do HDMI or DP out. I know the nouveau driver isn't as good, but I only need it to do basic mirror display and power management (turn the chip off when I don't use it). It manages to do this on my P70, but not my P73 yet. At this point I'm still trying to get confirmation of whether nouveau is supposed to work on my chip, or not yet, but it's been 2 years since my first post since I got this new laptop (then) and no luck yet. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08
Re: [Nouveau] 6.2 still cannot get hdmi display out on Thinkpad P73 Quadro RTX 4000 Mobile/TU104
On Thu, May 04, 2023 at 10:43:21PM -0500, Steven Kucharzyk wrote: > On Thu, 4 May 2023 16:32:16 -0700 > Marc MERLIN wrote: > > > Hi again, I just saw a bunch of commits from all of you (thanks), but > > still can't find info if my thinkpad P73 with Quadro RTX 4000 > > Mobile/TU104 is meant to be supported, or not, and if so, how I can > > best report issues beyond what I've already sent. > > > > The intel graphics works great thankfully, but I do need to use HDMI > > out from time to time, which is only wired to the nvidia chip > > unfortunately. > > > > Guidance would be very appreciated. > > I'm going to take a leap here ... > > any UEFI ? TSM ? Yes, I boot with UEFI. Not sure what TSM means > In the spec's that I looked at Lenovo's ThinkPad P73 FHD / 4K UHD > personally I found it interesting that the "up to" Nvidia Quadro RTX > 5000 was listed as "Discrete" vs. the UHD Graphics 620 (24 EUs) as > "Integrated". Are you 4K? 4K correct. As far as I understand, I have integrated intel graphics, which is what I use every day, and that nvidia chip I never use and have no real need for, except that external display ports are only connected to that chip, so I have to use it in that case. I had a P70 with the same config and was able to get nouveau working on it and HDMI out, but P73 uses different chips and never fully got it working (well, the monitor turns on and I see a mouse cursor, so something works) https://docs.google.com/document/d/1GnyBE1xc4qx3EF-IcUOwr7d9D8Npzy63Pwj-joOw86o/view#heading=h.tmm3ssfqplva explains how I got it to work on P70 > HDMI ... I have had issues with Laps + HDMI when plugging the cable > into an already turn-on monitor. I have taken DVI-I > DP cables just to > see ... Next I didn't see any reference to Nvidia drivers is that your > option ? (I know, I live with bane of a "tainted kernel" because of > them and flop back and forth to see how Nouveau is progressing) I do not have plans to use the nvidia binary drivers and do want my nvidia chip to be turned off all the time except when I need video out (for battery reasons) If you wanted context/more info: https://www.spinics.net/lists/nouveau/msg11393.html https://www.spinics.net/lists/nouveau/msg11394.html and older from 2020: https://www.spinics.net/lists/nouveau/msg05361.html Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/
Re: [Nouveau] 6.2 still cannot get hdmi display out on Thinkpad P73 Quadro RTX 4000 Mobile/TU104
Hi again, I just saw a bunch of commits from all of you (thanks), but still can't find info if my thinkpad P73 with Quadro RTX 4000 Mobile/TU104 is meant to be supported, or not, and if so, how I can best report issues beyond what I've already sent. The intel graphics works great thankfully, but I do need to use HDMI out from time to time, which is only wired to the nvidia chip unfortunately. Guidance would be very appreciated. Thanks, Marc On Thu, Apr 20, 2023 at 10:46:20PM -0700, Marc MERLIN wrote: > Tested with 6.2.8 and still nothing. Is it meant to work at all? > > Intel graphics works, but as soon as I plug in external HDMI, nouveau outputs > huge amount of spam logs > but nothing seems to work > > nouveau: detected PR support, will not use DSM > nouveau :01:00.0: enabling device ( -> 0003) > Console: switching to colour dummy device 80x25 > nouveau :01:00.0: NVIDIA TU104 (164000a1) > nouveau :01:00.0: bios: version 90.04.4d.00.2c > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/nvdec/scrubber.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/acr/bl.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/acr/ucode_ahesasc.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/acr/bl.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/acr/ucode_asb.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/acr/unload_bl.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/acr/ucode_unload.bin > nouveau :01:00.0: pmu: firmware unavailable > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/fecs_bl.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/fecs_inst.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/fecs_data.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/fecs_sig.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/gpccs_bl.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/gpccs_inst.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/gpccs_data.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/gpccs_sig.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/sw_nonctx.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/sw_ctx.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/sw_bundle_init.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/gr/sw_method_init.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/sec2/sig.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/sec2/image.bin > nouveau :01:00.0: firmware: direct-loading firmware > nvidia/tu104/sec2/desc.bin > nouveau :01:00.0: disp: preinit running... > nouveau :01:00.0: disp: preinit completed in 0us > nouveau :01:00.0: disp: fini running... > nouveau :01:00.0: disp: fini completed in 0us > nouveau :01:00.0: fb: 8192 MiB GDDR6 > nouveau :01:00.0: disp: init running... > nouveau :01:00.0: disp: init skipped, engine has no users > nouveau :01:00.0: disp: init completed in 2us > nouveau :01:00.0: DRM: VRAM: 8192 MiB > nouveau :01:00.0: DRM: GART: 536870912 MiB > nouveau :01:00.0: DRM: BIT table 'A' not found > nouveau :01:00.0: DRM: BIT table 'L' not found > nouveau :01:00.0: DRM: TMDS table version 2.0 > nouveau :01:00.0: DRM: DCB version 4.1 > nouveau :01:00.0: DRM: DCB outp 00: 02800f66 04600020 > nouveau :01:00.0: DRM: DCB outp 01: 02011f52 00020010 > nouveau :01:00.0: DRM: DCB outp 02: 01022f36 04600010 > nouveau :01:00.0: DRM: DCB outp 03: 04033f76 04600010 > nouveau :01:00.0: DRM: DCB outp 04: 04044f86 04600020 > nouveau :01:00.0: DRM: DCB conn 00: 00020047 > nouveau :01:00.0: DRM: DCB conn 01: 00010161 > nouveau :01:00.0: DRM: DCB conn 02: 1248 > nouveau :01:00.0: DRM: DCB conn 03: 01000348 > nouveau :01:00.0: DRM: DCB conn 04: 02000471 > nouveau :01:00.0: DRM: MM: using COPY for buffer copies > nouveau :01:00.0: disp: init running... > nouveau :01:00.0: disp: one-time init running... > nouveau :01:00.0: disp: outp 00:0006:0f82: type 06 loc 0 or 2 link 2 con > 0 edid 6 bus 0 head f > nouveau :01:00.0: disp: outp 00:0006:0f82: bios dp 42 13 00 00 > nouveau :01:00.0: disp: outp 01:0002:0f42: type 02 loc 0 or 2 link 1 con > 1 edid 5 bus 1 head f > no
Re: [Nouveau] 6.2 still cannot get hdmi display out on Thinkpad P73 Quadro RTX 4000 Mobile/TU104
Tested with 6.2.8 and still nothing. Is it meant to work at all? Intel graphics works, but as soon as I plug in external HDMI, nouveau outputs huge amount of spam logs but nothing seems to work nouveau: detected PR support, will not use DSM nouveau :01:00.0: enabling device ( -> 0003) Console: switching to colour dummy device 80x25 nouveau :01:00.0: NVIDIA TU104 (164000a1) nouveau :01:00.0: bios: version 90.04.4d.00.2c nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/nvdec/scrubber.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/bl.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/ucode_ahesasc.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/bl.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/ucode_asb.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/unload_bl.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/ucode_unload.bin nouveau :01:00.0: pmu: firmware unavailable nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/fecs_bl.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/fecs_inst.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/fecs_data.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/fecs_sig.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/gpccs_bl.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/gpccs_inst.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/gpccs_data.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/gpccs_sig.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/sw_nonctx.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/sw_ctx.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/sw_bundle_init.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/sw_method_init.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/sec2/sig.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/sec2/image.bin nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/sec2/desc.bin nouveau :01:00.0: disp: preinit running... nouveau :01:00.0: disp: preinit completed in 0us nouveau :01:00.0: disp: fini running... nouveau :01:00.0: disp: fini completed in 0us nouveau :01:00.0: fb: 8192 MiB GDDR6 nouveau :01:00.0: disp: init running... nouveau :01:00.0: disp: init skipped, engine has no users nouveau :01:00.0: disp: init completed in 2us nouveau :01:00.0: DRM: VRAM: 8192 MiB nouveau :01:00.0: DRM: GART: 536870912 MiB nouveau :01:00.0: DRM: BIT table 'A' not found nouveau :01:00.0: DRM: BIT table 'L' not found nouveau :01:00.0: DRM: TMDS table version 2.0 nouveau :01:00.0: DRM: DCB version 4.1 nouveau :01:00.0: DRM: DCB outp 00: 02800f66 04600020 nouveau :01:00.0: DRM: DCB outp 01: 02011f52 00020010 nouveau :01:00.0: DRM: DCB outp 02: 01022f36 04600010 nouveau :01:00.0: DRM: DCB outp 03: 04033f76 04600010 nouveau :01:00.0: DRM: DCB outp 04: 04044f86 04600020 nouveau :01:00.0: DRM: DCB conn 00: 00020047 nouveau :01:00.0: DRM: DCB conn 01: 00010161 nouveau :01:00.0: DRM: DCB conn 02: 1248 nouveau :01:00.0: DRM: DCB conn 03: 01000348 nouveau :01:00.0: DRM: DCB conn 04: 02000471 nouveau :01:00.0: DRM: MM: using COPY for buffer copies nouveau :01:00.0: disp: init running... nouveau :01:00.0: disp: one-time init running... nouveau :01:00.0: disp: outp 00:0006:0f82: type 06 loc 0 or 2 link 2 con 0 edid 6 bus 0 head f nouveau :01:00.0: disp: outp 00:0006:0f82: bios dp 42 13 00 00 nouveau :01:00.0: disp: outp 01:0002:0f42: type 02 loc 0 or 2 link 1 con 1 edid 5 bus 1 head f nouveau :01:00.0: disp: outp 02:0006:0f41: type 06 loc 0 or 1 link 1 con 2 edid 3 bus 2 head f nouveau :01:00.0: disp: outp 02:0006:0f41: bios dp 42 13 00 00 nouveau :01:00.0: disp: outp 03:0006:0f44: type 06 loc 0 or 4 link 1 con 3 edid 7 bus 3 head f nouveau :01:00.0: disp: outp 03:0006:0f44: bios dp 42 13 00 00 nouveau :01:00.0: disp: outp 04:0006:0f84: type 06 loc 0 or 4 link 2 con 4 edid 8 bus 4 head f nouveau :01:00.0: disp: outp 04:0006:0f84: bios dp 42 13 00 00 nouveau :01:00.0: disp: conn 00:0047: type 47 loc 0 hpd 08 dp 0 di 0 sr 0 lcdid 0 nouveau :01:00.0: disp: conn 00:0047: func 52 (HPD) nouveau :01:00.0: disp: conn 01:0161: type 61 loc 1 hpd 04 dp 0 di 0 sr 0 lcdid 0 nouveau :01:00.0: disp: conn 01:0161: func 51 (HPD) nouveau :01:00.0: disp: conn 02:0248: type 48 loc 2 hpd 01 dp 0 di 0 sr 0 lcdid 0 nouveau :01:00.0: disp: conn 02:0248: func 07 (HPD) nouveau :01:00.0: disp: conn
Re: [Nouveau] 6.1 still cannot get display on Thinkpad P73Quadro RTX 4000 Mobile for hybrid graphics?
Howdy, I still have this: > sauron:~$ lspci |grep -i nvidia > 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX > 4000 Mobile / Max-Q] (rev a1) > 01:00.1 Audio device: NVIDIA Corporation TU104 HD Audio Controller (rev a1) > 01:00.2 USB controller: NVIDIA Corporation TU104 USB 3.1 Host Controller (rev > a1) > 01:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU104 USB Type-C > UCSI Controller (rev a1) Everything looks like it works when I run the commands, but I get no display outside of the X cursor. + xrandr --listproviders Providers: number : 2 Provider 0: id: 0x42 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 1 associated providers: 1 name:modesetting Provider 1: id: 0xe5 cap: 0x2, Sink Output crtcs: 4 outputs: 5 associated providers: 1 name:modesetting + xrandr + grep connected eDP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 382mm x 214mm panning 3840x2160+0+0 eDP-1-2 disconnected (normal left inverted right x axis y axis) HDMI-1-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 575mm x 323mm DP-1-1 disconnected (normal left inverted right x axis y axis) DP-1-2 disconnected (normal left inverted right x axis y axis) DP-1-3 disconnected (normal left inverted right x axis y axis) + grep modeset /var/log/Xorg.0.log + grep driver: [86.135] (II) modeset(0): [DRI2] DRI driver: i965 [86.135] (II) modeset(0): [DRI2] VDPAU driver: va_gl + echo 'route intel output to nvidia chip' route intel output to nvidia chip + xrandr --setprovideroutputsource 1 0 + xrandr + grep connected eDP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 382mm x 214mm panning 3840x2160+0+0 eDP-1-2 disconnected (normal left inverted right x axis y axis) HDMI-1-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 575mm x 323mm DP-1-1 disconnected (normal left inverted right x axis y axis) DP-1-2 disconnected (normal left inverted right x axis y axis) DP-1-3 disconnected (normal left inverted right x axis y axis) + xrandr --auto The 2nd screen shows up in xrandr or lxrandr, I can move it around, and I see my X cursor on the 2nd screen, but that's it, just the X cursor from enlightenment. I do not see any of my windows or anything else, only what enlightenent draws for the mouse, including some different looking mouse if I resize a window sauron:/sys/class/backlight# uname -r 6.1.0-7-amd64 sauron:/sys/class/backlight# dmesg | grep nouveau [6.643601] nouveau: detected PR support, will not use DSM [6.643619] nouveau :01:00.0: enabling device ( -> 0003) [6.643754] nouveau :01:00.0: NVIDIA TU104 (164000a1) [6.733717] nouveau :01:00.0: bios: version 90.04.4d.00.2c [6.734139] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/nvdec/scrubber.bin [6.734156] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/bl.bin [6.734169] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/ucode_ahesasc.bin [6.734182] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/bl.bin [6.734192] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/ucode_asb.bin [6.734220] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/unload_bl.bin [6.734230] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/acr/ucode_unload.bin [6.734236] nouveau :01:00.0: pmu: firmware unavailable [6.734359] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/fecs_bl.bin [6.734372] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/fecs_inst.bin [6.734381] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/fecs_data.bin [6.734390] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/fecs_sig.bin [6.734406] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/gpccs_bl.bin [6.734415] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/gpccs_inst.bin [6.734422] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/gpccs_data.bin [6.734430] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/gpccs_sig.bin [6.734442] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/sw_nonctx.bin [6.734453] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/sw_ctx.bin [6.734464] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/sw_bundle_init.bin [6.734476] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/gr/sw_method_init.bin [6.734495] nouveau :01:00.0: firmware: direct-loading firmware nvidia/tu104/sec2/sig.bin [6.734512] nouveau :01:00.0: firmware: direct-loading firmware
[Nouveau] 5.12.1 0010:nvkm_falcon_v1_wait_for_halt+0x8f/0xb9 [nouveau]
Howdy, I upgraded my thinkpad P73 from 5.9 to 5.12, and I now get this new ug at boot (although the system does continue booting and display works since I use i915 for display and only use nouveau for PM) Short: [ 18.561181] WARNING: CPU: 15 PID: 220 at drivers/gpu/drm/nouveau/nvkm/falcon/v1.c:247 nvkm_falcon_v1_wait_for_halt+0x8f/0xb9 [nouveau] [ 18.561300] Modules linked in: dm_crypt trusted tpm rng_core dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx multipath sata_sil24 r8169 realtek mdio_devres libphy mii hid_generic usbhid hid crct10dif_pclmul crc32_pclmul crc32c_intel xhci_pci rtsx_pci_sdmmc nouveau ghash_clmulni_intel xhci_hcd mmc_core e1000e i2c_designware_platform mxm_wmi i2c_designware_core hwmon ptp aesni_intel intel_lpss_pci drm_ttm_helper i2c_i801 crypto_simd intel_lpss i2c_smbus psmouse i915 cryptd pps_core thunderbolt rtsx_pci idma64 usbcore ttm i2c_nvidia_gpu thermal wmi battery [ 18.561636] CPU: 15 PID: 220 Comm: kworker/15:2 Tainted: G U 5.12.1-amd64-preempt-sysrq-20190817 #1 [ 18.561707] Hardware name: LENOVO 20QRS00200/20QRS00200, BIOS N2NET40W (1.25 ) 08/26/2020 [ 18.561765] Workqueue: pm pm_runtime_work [ 18.561799] RIP: 0010:nvkm_falcon_v1_wait_for_halt+0x8f/0xb9 [nouveau] Despite the warning, chip seems to go to sleep on batteries, poewertop shows an encouraging low battery use (my lowest one yet of any kernel): The battery reports a discharge rate of 10.7 W The power consumed was 230 J So it seems that what I need from nouveau is working (power management) Full warning below with logs Long: [0.00] Linux version 5.12.1-amd64-preempt-sysrq-20190817 (r...@sauron.svh.merlins.org) (gcc (Debian 10.2.1-3) 10.2.1 20201224, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP PREEMPT Wed May 5 13:05:02 PDT 2021 [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.12.1-amd64-preempt-sysrq-20190817 root=/dev/mapper/cryptroot ro rootflags=subvol=root cryptopts=source=/dev/nvme0n1p7,keyscript=/sbin/cryptgetpw usbcore.autosuspend=1 pcie_aspm=force resume=/dev/dm-1 acpi_backlight=vendor nouveau.debug=disp=trace [8.672663] nouveau :01:00.0: runtime IRQ mapping not provided by arch [8.677434] nouveau :01:00.0: enabling device ( -> 0003) [8.691872] nouveau :01:00.0: NVIDIA TU104 (164000a1) [8.789240] nouveau :01:00.0: bios: version 90.04.4d.00.2c [8.789605] nouveau :01:00.0: pmu: firmware unavailable [8.789897] nouveau :01:00.0: enabling bus mastering [8.789978] nouveau :01:00.0: disp: preinit running... [8.789981] nouveau :01:00.0: disp: preinit completed in 0us [8.789997] nouveau :01:00.0: disp: fini running... [8.78] nouveau :01:00.0: disp: fini completed in 0us [8.790189] nouveau :01:00.0: fb: 8192 MiB GDDR6 [8.800113] nouveau :01:00.0: disp: init running... [8.800116] nouveau :01:00.0: disp: init skipped, engine has no users [8.800118] nouveau :01:00.0: disp: init completed in 2us [8.801512] nouveau :01:00.0: DRM: VRAM: 8192 MiB [8.801515] nouveau :01:00.0: DRM: GART: 536870912 MiB [8.801517] nouveau :01:00.0: DRM: BIT table 'A' not found [8.801520] nouveau :01:00.0: DRM: BIT table 'L' not found [8.801521] nouveau :01:00.0: DRM: TMDS table version 2.0 [8.801525] nouveau :01:00.0: DRM: DCB version 4.1 [8.801527] nouveau :01:00.0: DRM: DCB outp 00: 02800f66 04600020 [8.801529] nouveau :01:00.0: DRM: DCB outp 01: 02011f52 00020010 [8.801531] nouveau :01:00.0: DRM: DCB outp 02: 01022f36 04600010 [8.801533] nouveau :01:00.0: DRM: DCB outp 03: 04033f76 04600010 [8.801535] nouveau :01:00.0: DRM: DCB outp 04: 04044f86 04600020 [8.801537] nouveau :01:00.0: DRM: DCB conn 00: 00020047 [8.801539] nouveau :01:00.0: DRM: DCB conn 01: 00010161 [8.801541] nouveau :01:00.0: DRM: DCB conn 02: 1248 [8.801543] nouveau :01:00.0: DRM: DCB conn 03: 01000348 [8.801543] nouveau :01:00.0: DRM: DCB conn 04: 02000471 [8.802234] nouveau :01:00.0: DRM: MM: using COPY for buffer copies [8.802255] nouveau :01:00.0: disp: init running... [8.802257] nouveau :01:00.0: disp: one-time init running... [8.802259] nouveau :01:00.0: disp: outp 00:0006:0f82: type 06 loc 0 or 2 link 2 con 0 edid 6 bus 0 head f [8.802265] nouveau :01:00.0: disp: outp 00:0006:0f82: bios dp 42 13 00 00 [8.802268] nouveau :01:00.0: disp: outp 01:0002:0f42: type 02 loc 0 or 2 link 1 con 1 edid 5 bus 1 head f [8.802272] nouveau :01:00.0: disp: outp 02:0006:0f41: type 06 loc 0 or 1 link 1 con 2 edid 3 bus 2 head f [8.802276] nouveau :01:00.0: disp: outp 02:0006:0f41: bios dp 42 13 00 00 [8.802279] nouveau :01:00.0: disp: outp 03:0006:0f44: type 06 loc 0 or 4 link 1 con 3 edid 7 bus 3 head f [8.802283] nouveau :01:00.0: disp: outp 03:0006:0f44: bios
Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)
On Fri, Jan 29, 2021 at 03:20:32PM -0600, Bjorn Helgaas wrote: > > For comparison the intel iwlwifi driver is very clear about firmware > > it's trying to load, if it can't and what exact firmware you need to > > find on the internet (filename) > > I guess you're referring to this in iwl_request_firmware()? > > IWL_ERR(drv, "check > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git\n"); > Yes :) > How can we fix this in nouveau so we don't have the debug this again? > I don't really know how firmware loading works, but "git grep -A5 > request_firmware drivers/gpu/drm/nouveau/" shows that we generally > print something when request_firmware() fails. Well, have a look at https://pastebin.com/dX19aCpj do you see any warning whatsoever? > But I didn't notice those messages in your logs, so I'm probably > barking up the wrong tree. you're not It seems that newer kernels are a bit better: [ 189.304662] nouveau :01:00.0: pmu: firmware unavailable [ 189.312455] nouveau :01:00.0: disp: destroy running... [ 189.316552] nouveau :01:00.0: disp: destroy completed in 1us [ 189.320326] nouveau :01:00.0: disp ctor failed, -12 [ 189.324214] nouveau: probe of :01:00.0 failed with error -12 So, it probably got better, but that message got displayed after the 2mn hang that having the firmware, stops from happening. whichever developer with the right hardware can probably easily reproduce this by removing the firmware and looking at the boot messages. At the very least, it should print something more clear "driver will not function properly", and a URL to where one can get the driver, would be awesome. > So maybe the wakeups are related to having vs not having the nouveau > firmware? I'm still curious about that, and it smells like a bug to > me, but probably something to do with nouveau where I have no hope of > debugging it. Right. Honestly, given the time I've lost with this, and now that it seems gone with the firmware, I'm happy to leave well enough alone :) I'm not sure how you are involved with the driver, but are you able to help improve the dmesg output? Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)
On Wed, Jan 27, 2021 at 03:33:00PM -0600, Bjorn Helgaas wrote: > Hi Marc, I appreciate your persistence on this. I am frankly > surprised that you've put up with this so long. Well, been using linux for 27 years, but also it's not like I have much of a choice outside of switching to windows, as tempting as it's getting sometimes ;) > > after boot, when it gets the right trigger (not sure which ones), it > > loops on this evern 2 seconds, mostly forever. > > > > I'm not sure if it's nouveau's fault or the kernel's PCI PME's fault, or > > something else. > > IIUC there are basically two problems: > > 1) A 2 minute delay during boot > Another random thought: is there any chance the boot delay could be > related to crypto waiting for entropy? So, the 2mn hang went away after I added the nouveau firwmare in initrd. The only problem is that the nouveau driver does not give a very good clue as to what's going on and what to do. For comparison the intel iwlwifi driver is very clear about firmware it's trying to load, if it can't and what exact firmware you need to find on the internet (filename) > 2) Some sort of event every 2 seconds that kills your battery life > Your machine doesn't sound unusual, and I haven't seen a flood of > similar reports, so maybe there's something unusual about your config. > But I really don't have any guesses for either one. Honestly, there are not too many thinpad P73 running linux out there. I wouldn't be surprised if it's only a handful or two. > It sounds like v5.5 worked fine and you first noticed the slow boot > problem in v5.8. We *could* try to bisect it, but I know that's a lot > of work on your part. I've done that in the past, to be honest now that it works after I added the firmware that nouveau started needing, and didn't need before, the hang at boot is gone for sure. The PCI PM wakeup issues on batteries happen sometimes still, but they are much more rare now. > Grasping for any ideas for the boot delay; could you boot with > "initcall_debug" and collect your "lsmod" output? I notice async_tx > in some of your logs, but I have no idea what it is. It's from > crypto, so possibly somewhat unusual? Is this still neeeded? I think of nouveau does a better job of helping the user correct the issue if firmware is missing (I think intel even gives a URL in printk), that would probably be what's needed for the most part. [ 12.832547] async_tx: api initialized (async) comes from ./crypto/async_tx/async_tx.c Thanks for your answer, let me know if there is anything else useful I can give, I think I'm otherwise mostly ok now. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)
On Mon, Jan 04, 2021 at 02:28:37PM +0100, Karol Herbst wrote: > mhh, that PCI config stuff should really not happen all the time, but > it also doesn't appear to. The other thing I really don't know is, how > well the runpm works with tools like TLP if there isn't only an audio > device, but also the USB stuff and all the subdevices have to be > turned off all the time in order for the GPU to stay powered down. > > The firmware stuff is also just a functional problem, so you won't get > display offloading, but it shouldn't drain your battery as long as > nothing is connected. I'd check with "grep . > /sys/bus/pci/devices/*/power/runtime_status" if all subdevices of the > GPU are powered down, and check which one gets enabled regularly or > something. Well, all I can say is that without the firmware, my boot hung 2mn every single time (I sent details in the logs upthread). The battery draw issue was inconsistent. I haven't quite found what triggers it yet. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)
On Tue, Dec 29, 2020 at 09:47:50AM -0800, Marc MERLIN wrote: > > Of course now that I read your email a bit more carefully, it seems > > your issue is with the "saving config space" messages. I'm not sure > > I've seen those before. Perhaps you have some sort of debug enabled. > > I'd find where in the kernel they are being produced, and what the > > conditions for it are. But the failure to load firmware isn't great -- > > not 100% sure if it impacts runpm or not. > > Yes, I have 'nouveau.debug=disp=trace' > Someone on this list asked me to add this a few months back. > > > I just double-checked, TU10x accel came in via > > afa3b96b058d87c2c44d1c83dadb2ba6998d03ce, which was first in v5.6. > > Initial TU10x support came in v5.0. So that doesn't line up with your > > timeline. > > You know, I said 5.5, maybe it was 5.6 now, it's been a little while > since those issues started. > > Now we know I was missing the required firmware, it's a good place to > start, so I'll start there, thank you very much for the pointers. Sorry for the delay. I rebooted and everything worked great. No hang at boot. As for the PME loop I've been seeing, it hasn't happened so far. I can't comment on whether firmware should be required for the kernel to boot properly, but if it's at all possible, please try to make the driver fall back or shut down if the firmware is absent as opposed to hanging the boot 2mn. Also some drivers give a better clue that their firmware is missing and where to get it from. Adding a printk to help users could be a good idea. Below is the boot with firmware present. Thanks for your help Marc sauron:~$ grep nouveau /var/log/dmesg [ 11.016605] nouveau: detected PR support, will not use DSM [ 11.025191] nouveau :01:00.0: runtime IRQ mapping not provided by arch [ 11.071823] nouveau :01:00.0: enabling device ( -> 0003) [ 11.111588] nouveau :01:00.0: NVIDIA TU104 (164000a1) [ 11.203598] nouveau :01:00.0: bios: version 90.04.4d.00.2c [ 11.203921] nouveau :01:00.0: pmu: firmware unavailable [ 11.204229] nouveau :01:00.0: enabling bus mastering [ 11.204543] nouveau :01:00.0: fb: 8192 MiB GDDR6 [ 11.215524] nouveau :01:00.0: DRM: VRAM: 8192 MiB [ 11.215525] nouveau :01:00.0: DRM: GART: 536870912 MiB [ 11.215527] nouveau :01:00.0: DRM: BIT table 'A' not found [ 11.215527] nouveau :01:00.0: DRM: BIT table 'L' not found [ 11.215528] nouveau :01:00.0: DRM: TMDS table version 2.0 [ 11.215529] nouveau :01:00.0: DRM: DCB version 4.1 [ 11.215530] nouveau :01:00.0: DRM: DCB outp 00: 02800f66 04600020 [ 11.215531] nouveau :01:00.0: DRM: DCB outp 01: 02011f52 00020010 [ 11.215532] nouveau :01:00.0: DRM: DCB outp 02: 01022f36 04600010 [ 11.215532] nouveau :01:00.0: DRM: DCB outp 03: 04033f76 04600010 [ 11.215533] nouveau :01:00.0: DRM: DCB outp 04: 04044f86 04600020 [ 11.215533] nouveau :01:00.0: DRM: DCB conn 00: 00020047 [ 11.215534] nouveau :01:00.0: DRM: DCB conn 01: 00010161 [ 11.215534] nouveau :01:00.0: DRM: DCB conn 02: 1248 [ 11.215535] nouveau :01:00.0: DRM: DCB conn 03: 01000348 [ 11.215535] nouveau :01:00.0: DRM: DCB conn 04: 02000471 [ 11.216166] nouveau :01:00.0: DRM: MM: using COPY for buffer copies [ 11.526753] nouveau :01:00.0: DRM: unknown connector type 48 [ 11.527077] nouveau :01:00.0: DRM: unknown connector type 48 [ 11.552051] nouveau :01:00.0: [drm] Cannot find any crtc or sizes [ 11.554239] nouveau :01:00.0: [drm] Cannot find any crtc or sizes [ 11.555822] nouveau :01:00.0: [drm] Cannot find any crtc or sizes [ 11.556054] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 1 [ 11.556060] nouveau :01:00.0: DRM: Disabling PCI power management to avoid bug [ 18.887229] nouveau :01:00.0: saving config space at offset 0x0 (reading 0x1eb610de) [ 18.887231] nouveau :01:00.0: saving config space at offset 0x4 (reading 0x100407) [ 18.887233] nouveau :01:00.0: saving config space at offset 0x8 (reading 0x3a1) [ 18.887235] nouveau :01:00.0: saving config space at offset 0xc (reading 0x80) [ 18.887237] nouveau :01:00.0: saving config space at offset 0x10 (reading 0xcd00) [ 18.887239] nouveau :01:00.0: saving config space at offset 0x14 (reading 0xa00c) [ 18.887241] nouveau :01:00.0: saving config space at offset 0x18 (reading 0x0) [ 18.887243] nouveau :01:00.0: saving config space at offset 0x1c (reading 0xb00c) [ 18.887245] nouveau :01:00.0: saving config space at offset 0x20 (reading 0x0) [ 18.887247] nouveau :01:00.0: saving config space at offset 0x24 (reading 0x2001) [ 18.887249] nouveau :01:00.0: saving config space at offset 0x28 (reading 0x0) [ 18.887251] nouveau :01:00.0: saving con
Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)
(removed other lists, since it's likely not a linux-PCI problem)
On Tue, Dec 29, 2020 at 11:33:16AM -0500, Ilia Mirkin wrote:
> > Sounds like this would be a problem with all chips if userspace is able
> > to wake them up every second or two with a probe. Now I wonder what
> > broken userspace I have that could be doing this.
>
> Well, it's a theory. Some userspace helpfully prevents the GPU from
> suspending entirely, unfortunately I don't remember its name though by
> messing with the attached audio device. It's very common and meant to
> help... oh well.
Are you thinking about tlp maybe? https://linrunner.de/tlp/
I submitted a blacklist patch so that it works ok-ish on my laptop now.
(when the nvidia chip is unhappy, it happily uses 70W on batteries with
1.3h of runtime. When everything is ok, I can go down to about 12W/9H)
> > Do you think that could be a reason why the boot would hang for 2 full
> > minutes at every
> > boot ever since I upgraded to 5.5?
>
> I'd have to check, but I'm guessing TU104 acceleration became a thing
> in 5.5. I would also not be very surprised if the code didn't handle
> failure extremely gracefully - there definitely have been problems
> with that in the past.
Ah, then the timing checks out. That's exciting, at least now I have a
lead as to why I'm having problems. This was the same time a PCI PM
change went in, and I mistakenly thought it was to blame.
> > The kernel module is in my initrd:
> > sauron:/usr/local/bin# dd
> > if=/boot/initrd.img-5.9.11-amd64-preempt-sysrq-20190817 bs=2966528 skip=1
> > | gunzip | cpio -tdv | grep nouveau
> > drwxr-xr-x 1 root root0 Nov 30 15:40
> > usr/lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau
> > -rw-r--r-- 1 root root 3691385 Nov 30 15:35
> > usr/lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau/nouveau.ko
> > 17+1 records in
> > 17+1 records out
> > 52566778 bytes (53 MB, 50 MiB) copied, 1.69708 s, 31.0 MB/s
>
> I think that gets you out of "full newbie" land...
:) (ok, I have been using linux since 1993, but stuff changes so much
all the time, that sometimes I feel like a newbie all over again)
In my days, we didn't complain about systemd vs sysvinit, we had rc.local
and it was good enough :-D
> > Note that ultimately I only need nouveau not to hang my boot 2mn and do
> > PM so that the nvidia chip goes to sleep since I don't use it.
>
> I'm not extremely familiar with debian packaging, but the firmware is
> provided by NVIDIA and shipped as part of linux-firmware:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia
Ah, it comes from outside just like intel firmware, thanks.
Also, I was looking for nouveau, not nvidia:
sauron:/usr/local/bin# dd
if=/boot/initrd.img-5.9.11-amd64-preempt-sysrq-20190817 bs=2966528 skip=1 |
gunzip | cpio -tdv | grep tu104
shows no match
Good news is that debian did package it (they have multiple firmware
packages)
sauron:~# dpkggrep firmware | awk '{print $1}' | xargs apt-get install -y
sauron:~# dpkg -S /lib/firmware/nvidia/tu104
firmware-misc-nonfree: /lib/firmware/nvidia/tu104
update-initramfs -v -c -k 5.9.11-amd64-preempt-sysrq-20190817
Ok, I should be in business after next reboot, thank you.
> Of course now that I read your email a bit more carefully, it seems
> your issue is with the "saving config space" messages. I'm not sure
> I've seen those before. Perhaps you have some sort of debug enabled.
> I'd find where in the kernel they are being produced, and what the
> conditions for it are. But the failure to load firmware isn't great --
> not 100% sure if it impacts runpm or not.
Yes, I have 'nouveau.debug=disp=trace'
Someone on this list asked me to add this a few months back.
> I just double-checked, TU10x accel came in via
> afa3b96b058d87c2c44d1c83dadb2ba6998d03ce, which was first in v5.6.
> Initial TU10x support came in v5.0. So that doesn't line up with your
> timeline.
You know, I said 5.5, maybe it was 5.6 now, it's been a little while
since those issues started.
Now we know I was missing the required firmware, it's a good place to
start, so I'll start there, thank you very much for the pointers.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)
On Sat, Dec 26, 2020 at 03:12:09AM -0800, Ilia Mirkin wrote: > > after boot, when it gets the right trigger (not sure which ones), it > > loops on this evern 2 seconds, mostly forever. > > The gpu suspends with runtime pm. And then gets woken up for some > reason (could be something quite silly, like lspci, or could be > something explicitly checking connectors, etc). Repeat. Ah, fair point. Could it be powertop even? How would I go towards tracing that? Sounds like this would be a problem with all chips if userspace is able to wake them up every second or two with a probe. Now I wonder what broken userspace I have that could be doing this. > Display offload usually requires acceleration -- the copies are done > using the DMA engine. Please make sure that you have firmware > available (and a new enough mesa). The errors suggest that you don't > have firmware available at the time that nouveau loads. Depending on > your setup, that might mean the firmware has to be built into the > kernel, or available in initramfs. (Or just regular filesystem if you > don't use a complicated boot sequence. But many people go with distro > defaults, which do have this complexity.) Hi Ilia, thanks for your answer. Do you think that could be a reason why the boot would hang for 2 full minutes at every boot ever since I upgraded to 5.5? Also, without wanting to sound like a full newbie, where is that firmware you're talking about? In my kernel source? Here's what I do have: sauron:/usr/local/bin# dpkggrep nouveau libdrm-nouveau2:amd64 install xserver-xorg-video-nouveau install no nouveau-firmware package in debian: sauron:/usr/local/bin# apt-cache search nouveau bumblebee - NVIDIA Optimus support for Linux libdrm-nouveau2 - Userspace interface to nouveau-specific kernel DRM services -- runtime xfonts-jmk - Jim Knoble's character-cell fonts for X xserver-xorg-video-nouveau - X.Org X server -- Nouveau display driver No firmware file on my disk: sauron:/usr/local/bin# find /lib/modules/5.9.11-amd64-preempt-sysrq-20190817/ /lib/firmware/ |grep nouveau /lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau /lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau/nouveau.ko sauron:/usr/local/bin# The kernel module is in my initrd: sauron:/usr/local/bin# dd if=/boot/initrd.img-5.9.11-amd64-preempt-sysrq-20190817 bs=2966528 skip=1 | gunzip | cpio -tdv | grep nouveau drwxr-xr-x 1 root root0 Nov 30 15:40 usr/lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau -rw-r--r-- 1 root root 3691385 Nov 30 15:35 usr/lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau/nouveau.ko 17+1 records in 17+1 records out 52566778 bytes (53 MB, 50 MiB) copied, 1.69708 s, 31.0 MB/s What am I supposed to do/check next? Note that ultimately I only need nouveau not to hang my boot 2mn and do PM so that the nvidia chip goes to sleep since I don't use it. Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)
This started with 5.5 and hasn't gotten better since then, despite some reports I tried to send. As per my previous message: I have a Thinkpad P70 with hybrid graphics. 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] (rev a2) that one works fine, I can use i915 for the main screen, and nouveau to display on the external ports (external ports are only wired to nvidia chip, so it's impossible to use them without turning the nvidia chip on). I now got a newer P73 also with the same hybrid graphics (setup as such in the bios). It runs fine with i915, and I don't need to use external display with nouveau for now (it almost works, but I only see the mouse cursor on the external screen, no window or anything else can get displayed, very weird). 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q] (rev a1) after boot, when it gets the right trigger (not sure which ones), it loops on this evern 2 seconds, mostly forever. I'm not sure if it's nouveau's fault or the kernel's PCI PME's fault, or something else. Boot hangs look like this: [ 10.659209] Console: switching to colour frame buffer device 240x67 [ 10.732353] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device [ 12.101203] nvidia-gpu :01:00.3: saving config space at offset 0x0 (reading 0x1ad910de) [ 12.101212] nvidia-gpu :01:00.3: saving config space at offset 0x4 (reading 0x100406) [ 12.101217] nvidia-gpu :01:00.3: saving config space at offset 0x8 (reading 0xc8000a1) [ 12.101223] nvidia-gpu :01:00.3: saving config space at offset 0xc (reading 0x80) [ 12.101228] nvidia-gpu :01:00.3: saving config space at offset 0x10 (reading 0xce054000) [ 12.101234] nvidia-gpu :01:00.3: saving config space at offset 0x14 (reading 0x0) [ 12.101239] nvidia-gpu :01:00.3: saving config space at offset 0x18 (reading 0x0) [ 12.101244] nvidia-gpu :01:00.3: saving config space at offset 0x1c (reading 0x0) [ 12.101249] nvidia-gpu :01:00.3: saving config space at offset 0x20 (reading 0x0) [ 12.101254] nvidia-gpu :01:00.3: saving config space at offset 0x24 (reading 0x0) [ 12.101259] nvidia-gpu :01:00.3: saving config space at offset 0x28 (reading 0x0) [ 12.101265] nvidia-gpu :01:00.3: saving config space at offset 0x2c (reading 0x229b17aa) [ 12.101270] nvidia-gpu :01:00.3: saving config space at offset 0x30 (reading 0x0) [ 12.101275] nvidia-gpu :01:00.3: saving config space at offset 0x34 (reading 0x68) [ 12.101280] nvidia-gpu :01:00.3: saving config space at offset 0x38 (reading 0x0) [ 12.101285] nvidia-gpu :01:00.3: saving config space at offset 0x3c (reading 0x4ff) [ 12.101333] nvidia-gpu :01:00.3: PME# enabled [ 25.151246] thunderbolt :06:00.0: saving config space at offset 0x0 (reading 0x15eb8086) [ 25.151260] thunderbolt :06:00.0: saving config space at offset 0x4 (reading 0x100406) [ 25.151265] thunderbolt :06:00.0: saving config space at offset 0x8 (reading 0x886) [ 25.151270] thunderbolt :06:00.0: saving config space at offset 0xc (reading 0x20) [ 25.151276] thunderbolt :06:00.0: saving config space at offset 0x10 (reading 0xcc10) [ 25.151281] thunderbolt :06:00.0: saving config space at offset 0x14 (reading 0xcc14) [ 25.151286] thunderbolt :06:00.0: saving config space at offset 0x18 (reading 0x0) [ 25.151291] thunderbolt :06:00.0: saving config space at offset 0x1c (reading 0x0) [ 25.151296] thunderbolt :06:00.0: saving config space at offset 0x20 (reading 0x0) [ 25.151301] thunderbolt :06:00.0: saving config space at offset 0x24 (reading 0x0) [ 25.151306] thunderbolt :06:00.0: saving config space at offset 0x28 (reading 0x0) [ 25.151311] thunderbolt :06:00.0: saving config space at offset 0x2c (reading 0x229b17aa) [ 25.151316] thunderbolt :06:00.0: saving config space at offset 0x30 (reading 0x0) [ 25.151322] thunderbolt :06:00.0: saving config space at offset 0x34 (reading 0x80) [ 25.151327] thunderbolt :06:00.0: saving config space at offset 0x38 (reading 0x0) [ 25.151332] thunderbolt :06:00.0: saving config space at offset 0x3c (reading 0x1ff) [ 25.151416] thunderbolt :06:00.0: PME# enabled [ 25.169204] pcieport :05:00.0: saving config space at offset 0x0 (reading 0x15ea8086) [ 25.169214] pcieport :05:00.0: saving config space at offset 0x4 (reading 0x100407) [ 25.169219] pcieport :05:00.0: saving config space at offset 0x8 (reading 0x6040006) [ 25.169224] pcieport :05:00.0: saving config space at offset 0xc (reading 0x10020) [ 25.169229] pcieport :05:00.0: saving config space at offset 0x10 (reading 0x0) [ 25.169233] pcieport :05:00.0: saving config space at offset 0x14 (reading 0x0) [ 25.169238] pcieport :05:00.0: saving config space at offset 0x18 (reading 0x60605) [
Re: [Nouveau] pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73)
On Sun, Sep 13, 2020 at 01:15:45PM -0700, Marc MERLIN wrote: > On Mon, Sep 07, 2020 at 05:29:35PM -0700, Marc MERLIN wrote: > > On Tue, Sep 08, 2020 at 01:51:19AM +0200, Karol Herbst wrote: > > > oh, I somehow missed that "disp ctor failed" message. I think that > > > might explain why things are a bit hanging. From the top of my head I > > > am not sure if that's something known or something new. But just in > > > case I CCed Lyude and Ben. And I think booting with > > > nouveau.debug=disp=trace could already show something relevant. > > > > Thanks. > > I've added that to my boot for next time I reboot. > > > > I'm moving some folks to Bcc now, and let's remove the lists other than > > nouveau on followups (lkml and pci). I'm just putting a warning here > > so that it shows up in other list archives and anyone finding this > > later knows that they should look in the nouveau archives for further > > updates/resolution. > > Hi, I didn't hear back on this issue. Did you need the > nouveau.debug=disp=trace > or are you already working on the "disp ctor failed" issue? I rebooted with the option you asked for: BOOT_IMAGE=/vmlinuz-5.8.5-amd64-preempt-sysrq-20190817 root=/dev/mapper/cryptroot ro rootflags=subvol=roo t cryptopts=source=/dev/nvme0n1p7,keyscript=/sbin/cryptgetpw usbcore.autosuspend=1 pcie_aspm=force resume=/dev/dm-1 acpi_backlight=ven dor nouveau.debug=disp=trace [8.371448] nouveau: detected PR support, will not use DSM [8.371458] nouveau :01:00.0: runtime IRQ mapping not provided by arch [8.371463] nouveau :01:00.0: enabling device ( -> 0003) [8.371510] Console: switching to colour dummy device 80x25 [8.371542] i915 :00:02.0: vgaarb: deactivate vga console [8.371574] nouveau :01:00.0: NVIDIA TU104 (164000a1) [8.373522] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [8.374215] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=mem [8.377328] i915 :00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [8.472037] nouveau :01:00.0: bios: version 90.04.4d.00.2c note that I still get a 3mn hang at boot here [ 188.334912] nouveau :01:00.0: disp: destroy running... [ 188.341741] nouveau :01:00.0: disp: destroy completed in 1us [ 188.344559] nouveau :01:00.0: disp ctor failed, -12 [ 188.347708] nouveau: probe of :01:00.0 failed with error -12 As a reminder: sauron:~# lspci |grep -i nvidia 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q] (rev a1) 01:00.1 Audio device: NVIDIA Corporation TU104 HD Audio Controller (rev a1) 01:00.2 USB controller: NVIDIA Corporation TU104 USB 3.1 Host Controller (rev a1) 01:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU104 USB Type-C UCSI Controller (rev a1) full boot still looks like this: [9.812614] Console: switching to colour frame buffer device 240x67 [9.844351] i915 :00:02.0: fb0: i915drmfb frame buffer device 16 seconds here? Why? [ 25.107472] thunderbolt :06:00.0: saving config space at offset 0x0 (reading 0x15eb8086) [ 25.107503] thunderbolt :06:00.0: saving config space at offset 0x4 (reading 0x100406) [ 25.107509] thunderbolt :06:00.0: saving config space at offset 0x8 (reading 0x886) [ 25.107514] thunderbolt :06:00.0: saving config space at offset 0xc (reading 0x20) [ 25.107520] thunderbolt :06:00.0: saving config space at offset 0x10 (reading 0xcc10) [ 25.107525] thunderbolt :06:00.0: saving config space at offset 0x14 (reading 0xcc14) [ 25.107530] thunderbolt :06:00.0: saving config space at offset 0x18 (reading 0x0) [ 25.107535] thunderbolt :06:00.0: saving config space at offset 0x1c (reading 0x0) [ 25.107540] thunderbolt :06:00.0: saving config space at offset 0x20 (reading 0x0) [ 25.107545] thunderbolt :06:00.0: saving config space at offset 0x24 (reading 0x0) [ 25.107550] thunderbolt :06:00.0: saving config space at offset 0x28 (reading 0x0) [ 25.107556] thunderbolt :06:00.0: saving config space at offset 0x2c (reading 0x229b17aa) [ 25.107561] thunderbolt :06:00.0: saving config space at offset 0x30 (reading 0x0) [ 25.107566] thunderbolt :06:00.0: saving config space at offset 0x34 (reading 0x80) [ 25.107571] thunderbolt :06:00.0: saving config space at offset 0x38 (reading 0x0) [ 25.107576] thunderbolt :06:00.0: saving config space at offset 0x3c (reading 0x1ff) [ 25.107661] thunderbolt :06:00.0: PME# enabled [ 25.125418] pcieport :05:00.0: saving config space at offset 0x0 (reading 0x15ea8086) [ 25.125448] pcieport :05:00.0: saving config space at offset 0x4 (reading 0x100407) [ 25.125454] pcieport :05:00.0: saving config sp
Re: [Nouveau] pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73)
On Mon, Sep 07, 2020 at 05:29:35PM -0700, Marc MERLIN wrote: > On Tue, Sep 08, 2020 at 01:51:19AM +0200, Karol Herbst wrote: > > oh, I somehow missed that "disp ctor failed" message. I think that > > might explain why things are a bit hanging. From the top of my head I > > am not sure if that's something known or something new. But just in > > case I CCed Lyude and Ben. And I think booting with > > nouveau.debug=disp=trace could already show something relevant. > > Thanks. > I've added that to my boot for next time I reboot. > > I'm moving some folks to Bcc now, and let's remove the lists other than > nouveau on followups (lkml and pci). I'm just putting a warning here > so that it shows up in other list archives and anyone finding this > later knows that they should look in the nouveau archives for further > updates/resolution. Hi, I didn't hear back on this issue. Did you need the nouveau.debug=disp=trace or are you already working on the "disp ctor failed" issue? Thanks Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73)
On Tue, Sep 08, 2020 at 01:51:19AM +0200, Karol Herbst wrote: > oh, I somehow missed that "disp ctor failed" message. I think that > might explain why things are a bit hanging. From the top of my head I > am not sure if that's something known or something new. But just in > case I CCed Lyude and Ben. And I think booting with > nouveau.debug=disp=trace could already show something relevant. Thanks. I've added that to my boot for next time I reboot. I'm moving some folks to Bcc now, and let's remove the lists other than nouveau on followups (lkml and pci). I'm just putting a warning here so that it shows up in other list archives and anyone finding this later knows that they should look in the nouveau archives for further updates/resolution. Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73)
On Mon, Sep 07, 2020 at 09:14:03PM +0200, Karol Herbst wrote: > > - changes in the nouveau driver. Mika told me the PCIe regression > > "pcieport :00:01.0: PME: Spurious native interrupt!" is supposed > > to be fixed in 5.8, but I still get a 4mn hang or so during boot and > > with 5.8, removing the USB key, didn't help make the boot faster > > that's the root port the GPU is attached to, no? I saw that message on > the Thinkpad P1G2 when runtime resuming the Nvidia GPU, but it does > seem to come from the root port. Hi Karol, thanks for your answer. 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 0d) 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q] (rev a1) > Well, you'd also need it when attaching external displays. Indeed. I just don't need that on this laptop, but familiar with the not so seemless procedure to turn on both GPUs, and mirror the intel one into the nvidia one for external output. > > [ 11.262985] nvidia-gpu :01:00.3: PME# enabled > > [ 11.303060] nvidia-gpu :01:00.3: PME# disabled > > mhh, interesting. I heard some random comments that the Nvidia > USB-C/UCSI driver is a bit broken and can cause various issues. Mind > blacklisting i2c-nvidia-gpu and typec_nvidia (and verify they don't > get loaded) and see if that helps? Right, this one: 01:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU104 USB Type-C UCSI Controller (rev a1) Sure, I'll blacklist it. Ok, just did that, removed from initrd, rebooted, and it was no better. >From initrd (before root gets mounted), I have this: nouveau 1961984 0 mxm_wmi16384 1 nouveau hwmon 32768 1 nouveau ttm 102400 1 nouveau wmi32768 2 nouveau,mxm_wmi I still got a 2mn hang. and a nouveau probe error [ 189.124530] nouveau: probe of :01:00.0 failed with error -12 Here's what it looks like: [9.693230] hid: raw HID events driver (C) Jiri Kosina [9.694988] usbcore: registered new interface driver usbhid [9.694989] usbhid: USB HID core driver [9.696700] hid-generic 0003:1050:0200.0001: hiddev0,hidraw0: USB HID v1.00 Device [Yubico Yubico Gnubby (gnubby1)] on usb-:00:14.0-2/input0 [9.784456] Console: switching to colour frame buffer device 240x67 [9.816297] i915 :00:02.0: fb0: i915drmfb frame buffer device [ 25.087400] thunderbolt :06:00.0: saving config space at offset 0x0 (reading 0x15eb8086) [ 25.087414] thunderbolt :06:00.0: saving config space at offset 0x4 (reading 0x100406) [ 25.087419] thunderbolt :06:00.0: saving config space at offset 0x8 (reading 0x886) [ 25.087424] thunderbolt :06:00.0: saving config space at offset 0xc (reading 0x20) [ 25.087430] thunderbolt :06:00.0: saving config space at offset 0x10 (reading 0xcc10) [ 25.087435] thunderbolt :06:00.0: saving config space at offset 0x14 (reading 0xcc14) [ 25.087440] thunderbolt :06:00.0: saving config space at offset 0x18 (reading 0x0) [ 25.087445] thunderbolt :06:00.0: saving config space at offset 0x1c (reading 0x0) [ 25.087450] thunderbolt :06:00.0: saving config space at offset 0x20 (reading 0x0) [ 25.087455] thunderbolt :06:00.0: saving config space at offset 0x24 (reading 0x0) [ 25.087460] thunderbolt :06:00.0: saving config space at offset 0x28 (reading 0x0) [ 25.087466] thunderbolt :06:00.0: saving config space at offset 0x2c (reading 0x229b17aa) [ 25.087471] thunderbolt :06:00.0: saving config space at offset 0x30 (reading 0x0) [ 25.087476] thunderbolt :06:00.0: saving config space at offset 0x34 (reading 0x80) [ 25.087481] thunderbolt :06:00.0: saving config space at offset 0x38 (reading 0x0) [ 25.087486] thunderbolt :06:00.0: saving config space at offset 0x3c (reading 0x1ff) [ 25.087571] thunderbolt :06:00.0: PME# enabled [ 25.105353] pcieport :05:00.0: saving config space at offset 0x0 (reading 0x15ea8086) [ 25.105364] pcieport :05:00.0: saving config space at offset 0x4 (reading 0x100407) [ 25.105370] pcieport :05:00.0: saving config space at offset 0x8 (reading 0x6040006) [ 25.105375] pcieport :05:00.0: saving config space at offset 0xc (reading 0x10020) [ 25.105380] pcieport :05:00.0: saving config space at offset 0x10 (reading 0x0) [ 25.105384] pcieport :05:00.0: saving config space at offset 0x14 (reading 0x0) [ 25.105389] pcieport :05:00.0: saving config space at offset 0x18 (reading 0x60605) [ 25.105394] pcieport :05:00.0: saving config space at offset 0x1c (reading 0x1f1) [ 25.105399] pcieport :05:00.0: saving config space at offset 0x20 (reading 0xcc10cc10) [ 25.105404] pcieport :05:00.0: saving config space at offset 0x24 (reading 0x1fff1) [ 25.105409] pcieport :05:00.0: saving config
Re: [Nouveau] pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73)
t offset 0x20 (reading 0xce00cd00) [6.724050] pcieport :00:01.0: saving config space at offset 0x24 (reading 0xb1f1a001) [6.724054] pcieport :00:01.0: saving config space at offset 0x28 (reading 0x0) [6.724058] pcieport :00:01.0: saving config space at offset 0x2c (reading 0x0) [6.724062] pcieport :00:01.0: saving config space at offset 0x30 (reading 0x0) [6.724066] pcieport :00:01.0: saving config space at offset 0x34 (reading 0x88) [6.724070] pcieport :00:01.0: saving config space at offset 0x38 (reading 0x0) [6.724074] pcieport :00:01.0: saving config space at offset 0x3c (reading 0x201ff) [6.724129] pcieport :00:1b.0: runtime IRQ mapping not provided by arch [6.724650] pcieport :00:1b.0: PME: Signaling with IRQ 123 [6.725021] pcieport :00:1b.0: saving config space at offset 0x0 (reading 0xa3408086) [6.725026] pcieport :00:1b.0: saving config space at offset 0x4 (reading 0x100407) [6.725031] pcieport :00:1b.0: saving config space at offset 0x8 (reading 0x60400f0) [6.725035] pcieport :00:1b.0: saving config space at offset 0xc (reading 0x81) [6.725040] pcieport :00:1b.0: saving config space at offset 0x10 (reading 0x0) [6.725044] pcieport :00:1b.0: saving config space at offset 0x14 (reading 0x0) [6.725049] pcieport :00:1b.0: saving config space at offset 0x18 (reading 0x20200) [6.725053] pcieport :00:1b.0: saving config space at offset 0x1c (reading 0x20f0) [6.725058] pcieport :00:1b.0: saving config space at offset 0x20 (reading 0xce30ce30) [6.725062] pcieport :00:1b.0: saving config space at offset 0x24 (reading 0x1fff1) [6.725067] pcieport :00:1b.0: saving config space at offset 0x28 (reading 0x0) [6.725071] pcieport :00:1b.0: saving config space at offset 0x2c (reading 0x0) [6.725075] pcieport :00:1b.0: saving config space at offset 0x30 (reading 0x0) [6.725080] pcieport :00:1b.0: saving config space at offset 0x34 (reading 0x40) [6.725084] pcieport :00:1b.0: saving config space at offset 0x38 (reading 0x0) [6.725089] pcieport :00:1b.0: saving config space at offset 0x3c (reading 0x201ff) [6.725154] pcieport :00:1c.0: runtime IRQ mapping not provided by arch [6.725284] pcieport :00:1c.0: PME: Signaling with IRQ 124 [6.725580] pcieport :00:1c.0: pciehp: Slot #0 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ [6.726086] pci_bus :04: dev 00, created physical slot 0 Any idea what's going on? Thanks, Marc On Sat, Aug 08, 2020 at 01:22:02PM -0700, Marc MERLIN wrote: > On Fri, Oct 04, 2019 at 03:39:46PM +0300, Mika Westerberg wrote: > > This is otherwise similar to pcie_wait_for_link() but allows passing > > custom activation delay in milliseconds. > > > > Signed-off-by: Mika Westerberg > > --- > > drivers/pci/pci.c | 21 ++--- > > 1 file changed, 18 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > > index e7982af9a5d8..bfd92e018925 100644 > > Hi Mika, > > So, I have a thinkpad P73 with thunderbolt, and while I don't boot > often, my last boots have been unreliable at best (was only able to boot > 5.7 once, and 5.8 did not succeed either). > > 5.6 was working for a while, but couldn't boot it either this morning, > so I had to go back to 5.5. This does not mean 5.5 does not have the > problem, just that it booted this morning, while 5.6 didn't when I > tried. > Once the kernel is booted, the problem does not seem to occur much, or > at all. > > Basically, I'm getting the same thing than this person with a P53 (which > is a mostly identical lenovo thinkpad, to mine) > kernel: pcieport :00:01.0: PME: Spurious native interrupt! > kernel: pcieport :00:01.0: PME: Spurious native interrupt! > kernel: pcieport :00:01.0: PME: Spurious native interrupt! > kernel: pcieport :00:01.0: PME: Spurious native interrupt! > kernel: pcieport :00:01.0: PME: Spurious native interrupt! > https://bbs.archlinux.org/viewtopic.php?id=250658 > > The kernel boots eventually, but it takes minutes, and everything is so > super slow, that I just can't reasonably use the machine. > > This shows similar issues with 5.3, 5.4. > https://forum.proxmox.com/threads/pme-spurious-native-interrupt-kernel-meldungen.62850/ > > Another report here with 5.6: > https://bugzilla.redhat.com/show_bug.cgi?id=1831899 > > My current kernel is running your patch above, and I haven't done a lot > of research yet to confirm whether going back to a kernel before it was > merged, fixes the problem. Unfortunately the problem is not consistent, > so it makes
Re: [Nouveau] 5.5 kernel: using nouveau or something else just long enough to turn off Quadro RTX 4000 Mobile for hybrid graphics?
On Sat, May 30, 2020 at 07:32:16PM +0200, Karol Herbst wrote: > > 5.5.11. I can put 5.6 if needed. > > please do. 5.5 is EOL and 5.4 and 5.6 got the runpm fixes in recent releases. Done, just went to 5.6.15, thanks. > no. It forces the audio device to be always on when on AC. there are > some sound power settings. > > SOUND_POWER_SAVE_CONTROLLER=Y > SOUND_POWER_SAVE_ON_AC=1 > SOUND_POWER_SAVE_ON_BAT=1 Thank you Karol and Ilia for the kind help, this totally worked. I filed a documentation bug on https://github.com/linrunner/TLP/issues/495 this will hopefully help other people. In other great news, I was able to mirror my display on HDMI through nouveau on the new kernel, thank you! xrandr --listproviders Providers: number : 2 Provider 0: id: 0x43 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 1 associated providers: 0 name:modesetting Provider 1: id: 0xf1 cap: 0x2, Sink Output crtcs: 4 outputs: 5 associated providers: 0 name:modesetting xrandr --setprovideroutputsource 1 0 [42753.806113] nouveau :01:00.0: DRM: allocated 2560x1600 fb: 0x20, bo e75d7ede [42753.806248] nouveau :01:00.0: fb1: nouveaudrmfb frame buffer device Thaks much, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 5.5 kernel: using nouveau or something else just long enough to turn off Quadro RTX 4000 Mobile for hybrid graphics?
On Fri, May 29, 2020 at 02:53:51PM -0400, Ilia Mirkin wrote: > > moving to new window moves the mouse, but not windows get displayed. > > Do you see anything in dmesg after this is set up? I'd expect some > errors about timeouts or something else. Nothing other than what I pasted. > Which kernel are you using? There have been some turing-specific fixes > recently. 5.5.11. I can put 5.6 if needed. > Also note that TLP has a problem where it forces the audio > sub-function to always-on which prevents the GPU from suspending. Ah, thanks for that. I have #RUNTIME_PM_DRIVER_BLACKLIST="amdgpu mei_me nouveau nvidia pcieport radeon" sauron:~$ lspci |grep -i nvidia 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q] (rev a1) 01:00.1 Audio device: NVIDIA Corporation TU104 HD Audio Controller (rev a1) 01:00.2 USB controller: NVIDIA Corporation TU104 USB 3.1 Host Controller (rev a1) 01:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU104 USB Type-C UCSI Controller (rev a1) So you're saying that I need to blacklist 01:00.1 and without that it hangs when suspending the powered off nvidia chip, which is what I'm experiencing as a hang when I unplug power? Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Home page: http://marc.merlins.org/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] 5.5 kernel: using nouveau or something else just long enough to turn off Quadro RTX 4000 Mobile for hybrid graphics?
Howdy, So, I have a Thinkpad P70 with hybrid graphics. 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] (rev a2) that one works fine, I can use i915 for the main screen, and nouveau to display on the external ports (external ports are only wired to nvidia chip, so it's impossible to use them without turning the nvidia chip on). I now got a newer P73 also with the same hybrid graphics (setup as such in the bios). It runs fine with i915, and I don't need to use external display with nouveau for now (it almost works, but I only see the mouse cursor on the external screen, no window or anything else can get displayed, very weird). 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q] (rev a1) What I need for now is either nouveau, or bbswitch if it still works to turn the nvidia chip off every time I power on/reboot/plug/unplug external power. if I don't load the nouveau module, I get this in powertop: Bad Runtime PM for PCI Device NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q] powertop cannot really turn it off and I get The battery reports a discharge rate of 63.0 W If I load the nouveau driver, the chip gets turned off (great), but it's unstable and hard crashes my laptop when I plug/unplug it from power after a few times. This is what I got in my logs after the last crash: intel-lpss :00:15.0: power state changed by ACPI to D3cold intel-lpss :00:15.1: power state changed by ACPI to D3cold snd_hda_intel :00:1f.3: PME# enabled intel-lpss :00:1e.0: power state changed by ACPI to D3cold snd_hda_intel :00:1f.3: power state changed by ACPI to D3hot xhci_hcd :01:00.2: PME# enabled nvidia-gpu :01:00.3: PME# enabled pcieport :05:00.0: PME# enabled xhci_hcd :2c:00.0: PME# enabled pcieport :05:02.0: PME# enabled pcieport :04:00.0: PME# enabled pcieport :00:1c.0: PME# enabled pcieport :00:1c.0: power state changed by ACPI to D3cold nouveau :01:00.0: power state changed by ACPI to D3cold pcieport :00:01.0: PME# enabled pcieport :00:01.0: power state changed by ACPI to D3cold I am using TLP to manage battery use, the driver might not like things getting turned off to save power (although when it works, I can get the laptop down to 10W) Any suggestions on my best way to just keep the nvidia chip off reliably? nouveau? bbswitch? other? (and before you ask, no, you cannot turn it off in the bios, it's hybrid or nvidia only) If that helps, here is what I got when I tried to use hybrid graphics to power an external monitor (just pasting for completeness, I don't need this to work for now) pci :01:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle nouveau: detected PR support, will not use DSM nouveau :01:00.0: runtime IRQ mapping not provided by arch nouveau :01:00.0: NVIDIA TU104 (164000a1) nouveau :01:00.0: bios: version 90.04.4d.00.2c nouveau :01:00.0: enabling bus mastering nouveau :01:00.0: fb: 8192 MiB GDDR6 vga_switcheroo: enabled [TTM] Zone kernel: Available graphics memory: 32730618 KiB [TTM] Zone dma32: Available graphics memory: 2097152 KiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator nouveau :01:00.0: DRM: VRAM: 8192 MiB nouveau :01:00.0: DRM: GART: 536870912 MiB nouveau :01:00.0: DRM: BIT table 'A' not found nouveau :01:00.0: DRM: BIT table 'L' not found nouveau :01:00.0: DRM: TMDS table version 2.0 nouveau :01:00.0: DRM: DCB version 4.1 nouveau :01:00.0: DRM: DCB outp 00: 02800f66 04600020 nouveau :01:00.0: DRM: DCB outp 01: 02011f52 00020010 nouveau :01:00.0: DRM: DCB outp 02: 01022f36 04600010 nouveau :01:00.0: DRM: DCB outp 03: 04033f76 04600010 nouveau :01:00.0: DRM: DCB outp 04: 04044f86 04600020 nouveau :01:00.0: DRM: DCB conn 00: 00020047 nouveau :01:00.0: DRM: DCB conn 01: 00010161 nouveau :01:00.0: DRM: DCB conn 02: 1248 nouveau :01:00.0: DRM: DCB conn 03: 01000348 nouveau :01:00.0: DRM: DCB conn 04: 02000471 nouveau :01:00.0: DRM: failed to create kernel channel, -22 nouveau :01:00.0: DRM: MM: using COPY for buffer copies nouveau :01:00.0: DRM: unknown connector type 48 nouveau :01:00.0: DRM: unknown connector type 48 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. memmap_init_zone_device initialised 2097152 pages in 16ms nouveau :01:00.0: DRM: DMEM: registered 8192MB of device memory nouveau :01:00.0: DRM: allocated 2560x1600 fb: 0x20, bo 18f13ee1 nouveau :01:00.0: fb1: nouveaudrmfb frame buffer device sauron:~$ xrandr --setprovideroutputsource 1 0 sauron:~$ xrandr --listactivemonitors Monitors: 1 0: +*eDP-1 3840/382x2160/214+0+0 eDP-1 sauron:~$ xrandr --auto sauron:~$ xrandr --listactivemonitors
