Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp633914ybv; Sat, 22 Feb 2020 11:06:14 -0800 (PST) X-Google-Smtp-Source: APXvYqx2zAdUz4IDEXHNsqin6EpPA1OSt0femweIKxjQYmmwjT1w6uRhcpU0cDw66Nyf2uYZSYMG X-Received: by 2002:a9d:34c:: with SMTP id 70mr31869874otv.174.1582398373978; Sat, 22 Feb 2020 11:06:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582398373; cv=none; d=google.com; s=arc-20160816; b=r11F+HIheJ2q74fR+oMsie7ns2GL2AuqAOXxTlyeKtb4S72aWhJ4DJoHcx+XNpZHz8 A1BCb+9IDC0HnMOcmmuc9O7FhyCDUrNxy4WhoU7+7jmRa2qBI3d5Fy7RXoASEz0QYHUK MBvKKjtBMGx1my3h44QxYcK3aaX6nTNzMnx9E7gIT+u80+CtKRVj4AgrmW/VJfOYHwGT YKIxR3VwoEZbH1/eu58qd4oqM+cpnbu3Mb4uiLQhKOaemUgJajNvs6jiV3f5du2cic+H TpJsIlEJSpXdZS2CYkCWBwAXBAkedsqG0X7oxvFfCf0I4I+lnPmEc5c0VAoKMI4znlVE oy2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=+dsYkY6brW/7UfgFdDaX+h/ueyclzrR+0QSsM2U4Rlk=; b=VxDKApTQ4fCM+R8NJvi3Vc5kcUTprspPHovWP1Z0GIiLst/JCwiSFKYeLfmCWDHjaN hZe0C70EGZa/9LGbDdgz0fLtthfYmGItAFV4nfY7UMfS9VLesViZslDeHTj/ASYTQMEX M8V9mQiNJ3Rcnxe31ws4JdOGmpBZxziG3f8w0XeS9KJF7EO4Sop232+yEBKtLjL85o0N PD7kLswV7O7tKLFDm7x+1qzxdjUbXUK1IY84ERO3wmHBcdcTiwJaONSS3+w6Kw3tnxB+ ukr4j/J40N1jex6xaddskyUNgacTfG9IZO0Gmq/xosOIS7V/trJPoV1+hg/Zpb+Tf9uV OdJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=UhHwTGpr; 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 l17si3673281otk.218.2020.02.22.11.06.01; Sat, 22 Feb 2020 11:06:13 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=UhHwTGpr; 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 S1726924AbgBVTFj (ORCPT + 99 others); Sat, 22 Feb 2020 14:05:39 -0500 Received: from mail-pj1-f66.google.com ([209.85.216.66]:39755 "EHLO mail-pj1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726758AbgBVTFj (ORCPT ); Sat, 22 Feb 2020 14:05:39 -0500 Received: by mail-pj1-f66.google.com with SMTP id e9so2240795pjr.4; Sat, 22 Feb 2020 11:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+dsYkY6brW/7UfgFdDaX+h/ueyclzrR+0QSsM2U4Rlk=; b=UhHwTGpr8XGGqFHQZaCGalRqVDMskiksqNnGCBkSGDIivHvN2N/lVC49aSAYyyIxtK tvPfMWlGOAWyO+Yly+Gxb2wWcw8k3xzBLQtKuUbdW7hqYXJg07Q3qmIMGy3k5eUeWcjV n6Kw7808y+/rN1edpm1s2RCBn0Poc764WXGqfoDHA6qD+w6Fe5fmKCdZp2N08jAyOF4g 4vlT/lfbSnxx7fUM9DXdJ19b5MrCX2kHlW9ROF7c2wLnFgG2LOfLcTkb5NmreDxEk1kr 455+REeVKBEA/NkPSgGTjyXQ/WrsIsVbRB2VuwTpEr2ER/SW0by4R6geN1CiI4ntgzAe stNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+dsYkY6brW/7UfgFdDaX+h/ueyclzrR+0QSsM2U4Rlk=; b=YF62K8KqbTs7+ED3Sh9YlKc0JXAHOZhhBZjLs3aL3T+0pNYGbE+30RFUdWisxUvnA4 eoSGNaUT78lqPf2Ptf58cahqPQBRCBe1j0xqqdiNBBCCEE4GkfNTcTEIHg9a/U9q5/SV ENVa5TbMPdvdhv+GeVUqEuKRipmDJZhl0lNzsR4mgf7EIN3DfyZlL2k/YZhJqdnKb4zW lVpGxveAHfIhcs+1i67S125fKL+a+LJUPaGngleoo+qhwkOeQayfWHiOCgbNYdOPZQqW XautrUuLqvlt8LtobgJEXqfmr5SNTsGWpdBUO6MtcO/LoWNmUBuf/uetkRSJaf11bBts HwqA== X-Gm-Message-State: APjAAAWqcxJvtZxopCK1gVEuYIELDXEaHPGiuPJtXFOrB4iudr+ptWPu BiRJdVEy91FXMGbDP94ZJW+kEKHQ X-Received: by 2002:a17:90a:c385:: with SMTP id h5mr10520064pjt.122.1582398337675; Sat, 22 Feb 2020 11:05:37 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id l21sm6790540pgo.33.2020.02.22.11.05.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Feb 2020 11:05:36 -0800 (PST) Subject: Re: [regression] nct6775 does not load in 5.4 and 5.5, bisected to b84398d6d7f90080 To: Martin Volf Cc: Mika Westerberg , Jean Delvare , Wolfram Sang , linux-i2c@vger.kernel.org, linux-hwmon@vger.kernel.org, Linux Kernel Mailing List References: <1bdbac08-86f8-2a57-2b0d-8cd2beb2a1c0@roeck-us.net> From: Guenter Roeck Message-ID: <85356d1a-f90d-e94d-16eb-1071d4e94753@roeck-us.net> Date: Sat, 22 Feb 2020 11:05:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/22/20 9:55 AM, Martin Volf wrote: > Hello, > > On Sat, Feb 22, 2020 at 4:41 PM Guenter Roeck wrote: >> On 2/22/20 3:13 AM, Martin Volf wrote: >>> hardware monitoring sensors NCT6796D on my Asus PRIME Z390M-PLUS >>> motherboard with Intel i7-9700 CPU don't work with 5.4 and newer linux >>> kernels, the driver nct6775 does not load. >>> >>> It is working OK in version 5.3. I have used almost all released stable >>> versions from 5.3.8 to 5.3.16; I didn't try older kernels. > ... >> My wild guess would be that the i801 driver is a bit aggressive with >> reserving memory spaces, but I don't immediately see what it does >> differently in that regard after the offending patch. Does it work >> if you unload the i2c_i801 driver first ? > > Yes, after unloading i2c_i801, the nct6775 works. There is definitely > some sort of race between these two drivers. Mostly i2c_i801 wins, but it > happened twice that nct6775 got automatically loaded just before i2c_i801 > and the sensors worked. > >> You could also try to compare the output of /proc/ioports with >> the old and the new kernel, and see if the IO address space used >> by nct6775 in v5.3 is assigned to the i801 driver (or some other >> driver, such as the watchdog driver) in v5.4. > > This is diff of /proc/ioports in 5.3.18 with loaded nct6775 and in > 5.4.21 without: > > --- ioports-5.3.18 > +++ ioports-5.4.21 > @@ -2,6 +2,7 @@ > 0000-001f : dma1 > 0020-0021 : pic1 > 002e-0031 : iTCO_wdt > + 002e-0031 : iTCO_wdt > 0040-0043 : timer0 > 0050-0053 : timer1 > 0060-0060 : keyboard > @@ -14,11 +15,10 @@ > 00f0-00ff : fpu > 00f0-00f0 : PNP0C04:00 > 0290-029f : pnp 00:01 > - 0295-0296 : nct6775 > - 0295-0296 : nct6775 > 03c0-03df : vga+ > 03f8-03ff : serial > 0400-041f : iTCO_wdt > + 0400-041f : iTCO_wdt > 0680-069f : pnp 00:03 > 0cf8-0cff : PCI conf1 > 0d00-ffff : PCI Bus 0000:00 > >> If you are into hacking the kernel, you could also add some >> debug messages into the nct6775 driver to find out where exactly >> it fails. If that helps, maybe we can then add those messages into >> into the driver source to help others if this is observed again. > > I have added some pr_info calls, the diff is at the and of this massage. > > "bad" dmesg (i.e. i2c_i801 loaded before modprobe nct6775) > > [ 1631.975392] nct6775: ### sensors_nct6775_init: > platform_driver_register() -> 0x0 > [ 1631.975396] nct6775: ### nct6775_find: superio_enter(0x2e) -> 0xfffffff0 > [ 1631.975417] nct6775: ### nct6775_find: superio_enter(0x4e) -> 0x0 > [ 1631.975455] nct6775: ### nct6775_find: (val & SIO_ID_MASK) == 0xffff > > "good" dmesg (rmmod i2c_i801; modprobe nct6775) > > [ 1730.751188] nct6775: ### sensors_nct6775_init: > platform_driver_register() -> 0x0 > [ 1730.751213] nct6775: ### nct6775_find: superio_enter(0x2e) -> 0x0 > [ 1730.751251] nct6775: ### nct6775_find: (val & SIO_ID_MASK) == 0xd42b > [ 1730.751359] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > [ 1730.751367] ACPI Warning: SystemIO range > 0x0000000000000295-0x0000000000000296 conflicts with OpRegion > 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) > (20190816/utaddress-204) > [ 1730.751379] ACPI: This conflict may cause random problems and > system instability > [ 1730.751381] ACPI: If an ACPI driver is available for this device, > you should use it instead of the native driver > [ 1730.751431] nct6775: ### nct6775_probe: platform_get_resource() -> 0xfdac7b00 > [ 1730.751434] nct6775: ### nct6775_probe: devm_request_region() -> 0 > [ 1730.751554] nct6775 nct6775.656: Invalid temperature source 28 at > index 0, source register 0x100, temp register 0x73 > [ 1730.751588] nct6775 nct6775.656: Invalid temperature source 28 at > index 1, source register 0x200, temp register 0x75 > [ 1730.751686] nct6775 nct6775.656: Invalid temperature source 28 at > index 4, source register 0x900, temp register 0x7b > [ 1730.751865] nct6775: ### nct6775_probe: superio_enter(0x2e) -> 0x0 > [ 1730.753685] nct6775: ### nct6775_find: superio_enter(0x4e) -> 0x0 > [ 1730.753722] nct6775: ### nct6775_find: (val & SIO_ID_MASK) == 0xffff > > So 0x2e is the resource the two drivers are fighting for. > Yes, and it should not do that, since the range can be used to access different segments of the same chip from multiple drivers. This region should only be reserved temporarily, using request_muxed_region() when needed and release_region() after the access is complete. Either case, I don't immediately see why that region would be interesting for the iTCO watchdog driver. Can you add some debugging into the i801 driver to see what memory regions it reserves, and how it gets to reserve 0x2e..0x31 ? That range really doesn't make any sense to me. Thanks, Guenter > I have created /etc/modprobe.d/nct6775-before-i2c_i801.conf with > install i2c_i801 /sbin/modprobe nct6775; /sbin/modprobe > --ignore-install i2c_i801 > > and it is working. I'm OK with this workaround, but I can do more > experiments if you instruct me what to try. > > Thanks, > > Martin > > --8<-- > --- nct6775.c.orig > +++ nct6775.c > @@ -3806,10 +3806,13 @@ static int nct6775_probe(struct platform > int num_attr_groups = 0; > > res = platform_get_resource(pdev, IORESOURCE_IO, 0); > +pr_info("### nct6775_probe: platform_get_resource() -> 0x%x\n", res); > if (!devm_request_region(&pdev->dev, res->start, IOREGION_LENGTH, > DRVNAME)) > return -EBUSY; > > +pr_info("### nct6775_probe: devm_request_region() -> 0"); > + > data = devm_kzalloc(&pdev->dev, sizeof(struct nct6775_data), > GFP_KERNEL); > if (!data) > @@ -4318,6 +4321,7 @@ static int nct6775_probe(struct platform > > break; > default: > +pr_info("### nct6775_probe: data->kind == 0x%x\n", data->kind); > return -ENODEV; > } > data->have_in = BIT(data->in_num) - 1; > @@ -4503,6 +4507,7 @@ static int nct6775_probe(struct platform > nct6775_init_device(data); > > err = superio_enter(sio_data->sioreg); > +pr_info("### nct6775_probe: superio_enter(0x%x) -> 0x%x\n", > sio_data->sioreg, err); > if (err) > return err; > > @@ -4729,6 +4734,7 @@ static int __init nct6775_find(int sioad > int addr; > > err = superio_enter(sioaddr); > +pr_info("### nct6775_find: superio_enter(0x%x) -> 0x%x\n", sioaddr, err); > if (err) > return err; > > @@ -4737,6 +4743,7 @@ static int __init nct6775_find(int sioad > if (force_id && val != 0xffff) > val = force_id; > > +pr_info("### nct6775_find: (val & SIO_ID_MASK) == 0x%04x\n", val); > switch (val & SIO_ID_MASK) { > case SIO_NCT6106_ID: > sio_data->kind = nct6106; > @@ -4831,6 +4838,7 @@ static int __init sensors_nct6775_init(v > int sioaddr[2] = { 0x2e, 0x4e }; > > err = platform_driver_register(&nct6775_driver); > +pr_info("### sensors_nct6775_init: platform_driver_register() -> 0x%x\n", err); > if (err) > return err; >