[Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50
On a very specific subset of ThinkPad P50 SKUs, particularly ones that come with a Quadro M1000M chip instead of the M2000M variant, the BIOS seems to have a very nasty habit of not always resetting the secondary Nvidia GPU between full reboots if the laptop is configured in Hybrid Graphics mode. The reason for this happening is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 2. Allow the nvidia GPU to runtime suspend itself after being idle 3. Reboot the machine, the more sudden the better (e.g sysrq-b may help) 4. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will quite literally be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad sideaffects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002 Later on, this causes us to timeout trying to bring up the GR ctx: [ cut here ] nouveau :01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Modules linked in: nouveau mxm_wmi i915 crc32c_intel ttm i2c_algo_bit serio_raw drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops xhci_pci drm xhci_hcd i2c_core wmi video CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.0.0-rc5Lyude-Test+ #29 Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] RIP: 0010:gf100_grctx_generate+0x7b2/0x850 [nouveau] Code: 85 d2 75 04 48 8b 57 10 48 89 95 28 ff ff ff e8 b4 37 0e e1 48 8b 95 28 ff ff ff 48 c7 c7 b1 97 57 a0 48 89 c6 e8 5a 38 c0 e0 <0f> 0b e9 b9 fd ff ff 48 8b 85 60 ff ff ff 48 8b 40 10 48 8b 78 10 RSP: 0018:c90b77f0 EFLAGS: 00010286 RAX: RBX: 71af8000 RCX: RDX: 7f41dfe0 RSI: 7f415698 RDI: 7f415698 RBP: c90b78c8 R08: R09: R10: R11: R12: 72118000 R13: R14: a0551420 R15: c90b7818 FS: () GS:7f40() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 5644d0556ca8 CR3: 02214006 CR4: 003606f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: gf100_gr_init_ctxctl+0x27b/0x2d0 [nouveau] gf100_gr_init+0x5bd/0x5e0 [nouveau] gf100_gr_init_+0x61/0x70 [nouveau] nvkm_gr_init+0x1d/0x20 [nouveau] nvkm_engine_init+0xcb/0x210 [nouveau] nvkm_subdev_init+0xd6/0x230 [nouveau] nvkm_engine_ref.part.0+0x52/0x70 [nouveau] nvkm_engine_ref+0x13/0x20 [nouveau] nvkm_ioctl_new+0x12c/0x260 [nouveau] ? nvkm_fifo_chan_child_del+0xa0/0xa0 [nouveau] ? gf100_gr_dtor+0xe0/0xe0 [nouveau] nvkm_ioctl+0xe2/0x180 [nouveau] nvkm_client_ioctl+0x12/0x20 [nouveau] nvif_object_ioctl+0x47/0x50 [nouveau] nvif_object_init+0xc8/0x120 [nouveau] nvc0_fbcon_accel_init+0x5c/0x960 [nouveau] nouveau_fbcon_create+0x5a5/0x5d0 [nouveau] ? drm_setup_crtcs+0x27b/0xcb0 [drm_kms_helper] ? __lock_is_held+0x5e/0xa0 __drm_fb_helper_initial_config_and_unlock+0x27c/0x520 [drm_kms_helper] drm_fb_helper_hotplug_event.part.29+0xae/0xc0 [drm_kms_helper] drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper] nouveau_fbcon_output_poll_changed+0xb8/0x110 [nouveau] drm_kms_helper_hotplug_event+0x2a/0x40 [drm_kms_helper] drm_dp_send_link_address+0x176/0x1c0 [drm_kms_helper] drm_dp_check_and_send_link_address+0xa0/0xb0 [drm_kms_helper] drm_dp_mst_link_probe_work+0xa4/0xc0 [drm_kms_helper] process_one_work+0x22f/0x5c0 worker_thread+0x44/0x3a0 kthread+0x12b/0x150 ? wq_pool_ids_show+0x140/0x140 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x3a/0x50 irq event stamp: 22490 hardirqs last enabled at (22489): [] console_unlock+0x44d/0x5f0 hardirqs last disabled at (22490): [] trace_hardirqs_off_thunk+0x1a/0x1c softirqs last enabled at (22486): [] __do_softirq+0x330/0x44d softirqs last disabled at (22479): [] irq_exit+0xe5/0xf0 WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] ---[ end trace bf0976ed88b122a8 ]--- nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00
[Nouveau] [PATCH] drm/nouveau/falcon: fix a few indentation issues
From: Colin Ian King
There are a few statements that are indented incorrectly. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c
b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c
index 771e16a16267..a8bee1e046aa 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c
@@ -269,7 +269,7 @@ cmd_write(struct nvkm_msgqueue *priv, struct
nvkm_msgqueue_hdr *cmd,
commit = false;
}
- cmd_queue_close(priv, queue, commit);
+ cmd_queue_close(priv, queue, commit);
return ret;
}
@@ -347,7 +347,7 @@ nvkm_msgqueue_post(struct nvkm_msgqueue *priv, enum
msgqueue_msg_priority prio,
ret = cmd_write(priv, cmd, queue);
if (ret) {
seq->state = SEQ_STATE_PENDING;
- msgqueue_seq_release(priv, seq);
+ msgqueue_seq_release(priv, seq);
}
return ret;
@@ -373,7 +373,7 @@ msgqueue_msg_handle(struct nvkm_msgqueue *priv, struct
nvkm_msgqueue_hdr *hdr)
if (seq->completion)
complete(seq->completion);
- msgqueue_seq_release(priv, seq);
+ msgqueue_seq_release(priv, seq);
return 0;
}
--
2.20.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 109613] New: nouveau: KMS is broken on last kernels (9700M GT)
https://bugs.freedesktop.org/show_bug.cgi?id=109613 Bug ID: 109613 Summary: nouveau: KMS is broken on last kernels (9700M GT) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: kurnev...@gmail.com QA Contact: xorg-t...@lists.x.org Created attachment 143363 --> https://bugs.freedesktop.org/attachment.cgi?id=143363=edit dmesg logs from different kernels I have KMS broken on my laptop Acer Aspire 8930G after upgrading from 4.10.13 to 4.11.2 kernel (also checked 4.11.9, the last version 4.20.7 and some versions between). With kernel parameter 'nouveau.modeset=0' it boots fine. Here is a picture how it looks on the screen after modeset: https://imgur.com/a/kr3rbFJ Laptops's lspci: 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07) 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03) 00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 03) 01:00.0 VGA compatible controller: NVIDIA Corporation G96M [GeForce 9700M GT] (rev a1) 02:00.0 Ethernet controller: Qualcomm Atheros AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 05:00.0 Network controller: Intel Corporation WiFi Link 5100 -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Fwd: PSA: Mailman changes, From addresses no longer accurate
Hi all, Unfortunately, freedesktop.org's job of sending mail to a huge number of people whilst pretending to be other people, has just got even harder than it was. fd.o can no longer (at least for the moment) send mail with the From addresses of DMARC/DKIM/SPF-protected sender domains. When we try to do so, large providers reject the mail, despite DMARC records explicitly specifying that the mail should be accepted. Worse than that, not only does the immediate delivery attempt fail, but it punishes our sender reputation enough that _other_ mail delivery fails: after we hit a DMARC-related failure, large providers often refuse delivery attempts for mail from non-DMARC-protected domains. As a result, if the sender domain has a DMARC record, we rewrite the From address to be the list's address, preserving the original author in Reply-To. I'm chasing this up through a few channels, but in the meantime, please be aware that the From address on mails may no longer be accurate. If you are attempting to apply patches with git-am, please check that the commit author is not 'Person Name via listname-devel '. If you are replying privately to a list mail, please be _very_ careful that you are replying to the original sender (in Reply-To) and not the list itself. Cheers, Daniel -- Forwarded message - From: Daniel Stone Date: Mon, 11 Feb 2019 at 23:38 Subject: PSA: Mailman changes, From addresses no longer accurate To: , Hi all, We have hit another step change in aggressive anti-spam techniques from major mail providers. Over the past few days, we saw a huge spike in the number of mails we were failing to deliver to GMail and outlook.com in particular. It looks like it is now no longer acceptable for us to break DMARC/DKIM/SPF. These are DNS-based extensions to SMTP, which allow domains to publish policies as to who should be allowed to send email on their behalf. SPF provides source filtering, so e.g. freedesktop.org could specify that no-one should accept mail with a From: *@freedesktop.org unless it came from gabe.freedesktop.org. Mailman completely breaks this: if I specified a filter only allowing Google to send mail for @fooishbar.org, then anyone enforcing SPF would reject receipt of this mail, as it would arrive from fd.o with my From address. DKIM allows domains to publish a public key in DNS, inserting a header into mails sent from their domain cryptographically signing the value of named headers. Mailman breaks this too: changing the Sender header (such that bounces get processed by Mailman, rather than sending a deluge of out-of-office and mailbox-over-quota messages to whoever posts to the list) can break most DKIM signatures. Mailman adding the unsubscribe footer also breaks this; we could make it not add the footer, but in order to do so we'd have to convince ourselves that we were not decreasing our GDPR compliance. DMARC ties the two together, allowing domains to specify whether or not DKIM/SPF should be mandatory, and if they fail, what action should be taken. Despite some domains specifying a fail action of 'none' (receiving MTA to send an advisory report to a named email address, but still allow the email), it seems that popular services still interpret 'none' as 'reject'. As a result, Google in particular is dropping some number of our mails on the floor. This does _not_ just apply to mails which fail DMARC/DKIM/SPF: every mail we send that fails these filters (which is a lot - e.g. Intel and NVIDIA both have SPF) decreases our sender reputation with GMail and causes it to reject legitimate mails. I've reached out to Google through a couple of channels to see what we can do to increase our delivery rate to them. In the meantime, if your mail is hosted by Google, or Outlook, and you think you're missing mails - you probably are. Mailman has also now been reconfigured such that if it spots a potential DMARC violation, it rewrites the From address to be @lists.freedesktop.org, keeping the original author in Reply-To. It also strips DKIM headers. This seems to be about the best we can do, unless and until the major mail service providers offer us some alternate way to send mail. If you are replying privately to someone, you should check very carefully that you are replying to them and not to the list. Unfortunately we don't have a good answer in the long run. The latest published RFC at https://tools.ietf.org/html/rfc6377 suggests that there are no good solutions. If anyone is blessed with an abundance of time and familiar with the current email landscape, I would love to talk to you and get your help to work on this. Unfortunately we don't have the manpower to actually properly monitor email; it can often take a collapse in successful-delivery rates for us to notice. Ultimately, I suspect the best solution is to move most of our discussions to dedicated fora like GitLab issues, or something like Discourse. Fundamentally, the thing we're trying to do (send email to
