Received: by 10.223.176.46 with SMTP id f43csp761861wra; Wed, 24 Jan 2018 05:39:19 -0800 (PST) X-Google-Smtp-Source: AH8x226XOwwdvGV/cu1FD+mec/Vavp8qxUGOpsy5zPENWqQrnE3rAKid6Nz6rTZCnjxcZDzwXv7p X-Received: by 2002:a17:902:b43:: with SMTP id 61-v6mr8333050plq.127.1516801159031; Wed, 24 Jan 2018 05:39:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516801159; cv=none; d=google.com; s=arc-20160816; b=SylN0n4jcKMHDwiixM2iwWxcKQhpsn3UtdX5LlwIKkleCnimc0NeHUr6haIDbCv2CO 9Hr089I914wVN1NJ6BBJxOGq8LvJ6o7y+Bd89v0MavbSt5GYCKvKcyA5rWs5/j3D/UFP lMZhdLvLkDdsDrcCcKWPInQXr96MaMTQDgWOiPeJohmO8Uxo2459eWfaTLFwfvoCqHRy qQKtGoBnKsPuxAlw67Xbii1wRq5xACNRkMhJqrw58PMMZQ0FsjnkMAE61bjBxaS98KhQ Nz8Rogslp7cvD/eUqJ/ys4iJpMxdGkaAooVnN3tlVgSqsDA4ExK4wyIuWbyh6JMm+X8H m+MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=ceXYcAOKDECJWGkxgjv+0PSrCEBIbWt2hEpfAOku0ZE=; b=lGYgUpPaIysYSyjZj4oWlp156KNiWD0QT1Utx9vY/9dIOo/aX02vYzU1gzJQ2lnl/I sYIGDnkavYauUXsdF+FQAP6GYss2F0QRSHmeab8T9pOjs0VIUGuNzw9YEl2odOWuC2+g i65u3JSHhKO6MIaqKcKHtoUbNatRGK30R6UIMSIT0b1k+i6hOgyp6lmkFO2oEc0XwmmV U+H06ItlQLTGgRkvLMSq/6fabxNkDiffWlJsxLaLyVsy8otA0M7xMGzqBoqxCUTHjWEc 0avC4U/vVtWiNVsAyJ+5cAU9Evc+5Aiuco3Fgr97zrGWXhbVWpwrbcNoCh4FbH+bMXKA j+Tg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m14si158655pgd.207.2018.01.24.05.39.04; Wed, 24 Jan 2018 05:39:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933759AbeAXNi2 (ORCPT + 99 others); Wed, 24 Jan 2018 08:38:28 -0500 Received: from mail.skyhub.de ([5.9.137.197]:52206 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932187AbeAXNi0 (ORCPT ); Wed, 24 Jan 2018 08:38:26 -0500 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1q9HJukK4MUd; Wed, 24 Jan 2018 14:38:25 +0100 (CET) Received: from pd.tnic (p200300EC2BD0B300B5F6B1F16569F43D.dip0.t-ipconnect.de [IPv6:2003:ec:2bd0:b300:b5f6:b1f1:6569:f43d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 5C3CE1EC051E; Wed, 24 Jan 2018 14:38:25 +0100 (CET) Date: Wed, 24 Jan 2018 14:38:17 +0100 From: Borislav Petkov To: Thomas Gleixner , Yazen Ghannam Cc: Lyude Paul , "H. Peter Anvin" , keith.busch@intel.com, Ingo Molnar , "linux-kernel@vger.kernel.org" Subject: Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel Message-ID: <20180124133817.tb4hlaro555pyuqs@pd.tnic> References: <1516744873.29151.3.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 24, 2018 at 01:50:52PM +0100, Thomas Gleixner wrote: > On Tue, 23 Jan 2018, Lyude Paul wrote: > > > Hi! Sorry to be the bearer of bad news, but this patch actually seems to break > > suspending and resuming with nouveau on my machine: > > > [ 31.003578] WARNING: CPU: 0 PID: 11523 at kernel/smp.c:291 > > smp_call_function_single+0xdc/0xe0 > > This warning has absolutely no relationship to that patch. > > > [ 31.003592] RIP: 0010:smp_call_function_single+0xdc/0xe0 > > [ 31.003603] ? rdmsr_safe_on_cpu+0x4b/0x70 > > [ 31.003604] rdmsr_safe_on_cpu+0x4b/0x70 > > [ 31.003606] get_block_address.isra.0+0x6e/0xe0 > > [ 31.003607] mce_amd_feature_init+0x63/0x2c0 > > [ 31.003609] mce_syscore_resume+0x1e/0x30 > > [ 31.003611] syscore_resume+0x4b/0x170 > > [ 31.003613] suspend_devices_and_enter+0x608/0x7e0 > > [ 31.003614] pm_suspend+0x315/0x380 > > [ 31.003615] state_store+0x7d/0xe0 > > [ 31.003618] kernfs_fop_write+0xfa/0x180 > > [ 31.003620] __vfs_write+0x23/0x130 > > [ 31.003623] ? SYSC_newfstat+0x29/0x40 > > [ 31.003625] ? _cond_resched+0x15/0x40 > > [ 31.003626] vfs_write+0xad/0x1a0 > > [ 31.003627] SyS_write+0x42/0x90 > > [ 31.003629] entry_SYSCALL_64_fastpath+0x24/0x87 > > Borislav? Yeah cfee4f6f0b20 ("x86/mce/AMD: Read MSRs on the CPU allocating the threshold blocks") Yazen CCed. Non-core banks are accessible only on the node-base CPU or something like that. But we can't send IPIs with IRQs off, thus the warning. Yazen, I'm thinking this whole get_block_address() dancing can be simplified by creating a data structure containing *all* MCi_MISC* addresses once during boot and then using it instead of reading it from the MSRs each time. Also - and I'm wishfully thinking simple here - that structure could be global as I'd venture a guess that all MISC addresses are the same system-wide and not node-specific. But I might be missing something here. Hmmm. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.