From owner-freebsd-current@freebsd.org Wed May 27 19:12:55 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 620102CC69D for ; Wed, 27 May 2020 19:12:55 +0000 (UTC) (envelope-from db@db.net) Received: from tfm.com (mtbaker.tfm.com [192.231.224.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.tfm.com", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49XL7p028qz3yV5; Wed, 27 May 2020 19:12:53 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (DB-DSL.ServerNorth.com [98.124.61.131]) (authenticated bits=0) by tfm.com (8.14.4/8.14.4) with ESMTP id 04RJCgEZ011577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2020 12:12:45 -0700 (PDT) Date: Wed, 27 May 2020 15:12:42 -0400 From: Diane Bruce To: Andreas Nilsson Cc: cem@freebsd.org, "Andrey V. Elsukov" , Current FreeBSD Subject: Re: hwpstate_intel hangs kernel Message-ID: <20200527191242.GB13064@night.db.net> References: <20200521235659.GA14173@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 49XL7p028qz3yV5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of db@db.net has no SPF policy when checking 192.231.224.2) smtp.mailfrom=db@db.net X-Spamd-Result: default: False [0.75 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.53)[-0.535]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.33)[0.327]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[db.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.06)[0.062]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:10488, ipnet:192.231.224.0/22, country:US]; FREEMAIL_CC(0.00)[freebsd.org,yandex.ru] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 19:12:55 -0000 On Wed, May 27, 2020 at 08:25:52PM +0200, Andreas Nilsson wrote: > On Fri, May 22, 2020 at 1:57 AM Diane Bruce wrote: > > > On Wed, Feb 05, 2020 at 02:45:50PM +0100, Andreas Nilsson wrote: > > > > Ok I am going to respond to this old email from February.. > > > > > Hello, > > > > > > I upgraded to a newer version, git 87d669d3863-c266265, and I do not > > > experience the random hang anymore. The machine still hangs on boot on > > > "hwpstate_intel0: on cpu0" unless I set > > > 'hint.hwpstate_intel.0.disabled="1"' in loader.conf. > > > > > > > As a few others know on IRC I ran into exactly this same problem > > on a brand new Lenovo Carbon. I missed this thread somehow. > > I also had to bisect the commit. Would it be possible to put > > a note into UPDATING and default to disabled=1 for now? ;) > > > > > Well, I've been trying to chase this a bit more. But I could sure use some > help from more experienced kernel developers. > > debug.hwpstate_verbose="1" in loader.conf, and booting in verbose mode I > get this: > > pcib0: allocated type 4 (8x3f8-8xaf8) for rid 8 of uart0 > uart0 failed to probe at port 0x3f8 irg 4 on isa0 > pcib0: allocated type 4 (0x2f8-0x2f8) for rid 0 uart1 > uart1 failed to probe at port 0x2f8 irq 3 on isa0 > isa_probe_children: probing PnP devices > Acpi0sExecute: task queue not started > cpu0: hwpstate registered > Acpi0sExecute: task queue not started > cpu1: hwpstate registered > Acpi0sExecute; task queue not started > cpu2: hwpstate registered > Acpi0sExecute: task queue not started > cpu3: hwpstate registered > hwpstate_intel0: on cpu0 > hwpstate_intel0: hwpstate_attach1 > hwpstate_intel0: hwpstate_attach2 > hwpstate_intel0: hwpstate_attach3 > > where the hwpstate_attachX is some device_printf(dev,"hwpstate_attachX\n"); > I've sprinkled in to try to where it actually fails. > > I'm not sure about if device_printf happens immediately. The modifications > have been made to the function intel_hwpstate_attach around line 480 in > sys/x86/cpufreq/hwpstate_intel.c In my tests No it does not fail immediately it fails after a few minutes. Thinking that was a possible bogus setting I have tried this: +#if 0 sc->high = IA32_HWP_CAPABILITIES_HIGHEST_PERFORMANCE(caps); sc->guaranteed = IA32_HWP_CAPABILITIES_GUARANTEED_PERFORMANCE(caps); sc->efficient = IA32_HWP_CAPABILITIES_EFFICIENT_PERFORMANCE(caps); sc->low = IA32_HWP_CAPABILITIES_LOWEST_PERFORMANCE(caps); - +#else + sc->high = IA32_HWP_CAPABILITIES_HIGHEST_PERFORMANCE(caps); + sc->guaranteed = IA32_HWP_CAPABILITIES_HIGHEST_PERFORMANCE(caps); + sc->efficient = IA32_HWP_CAPABILITIES_HIGHEST_PERFORMANCE(caps); + sc->low = IA32_HWP_CAPABILITIES_HIGHEST_PERFORMANCE(caps); +#endif e.g. setting all the steps to the same state. It still hangs but not immediately. What is confounding the matter is the Lenovo bios also allows one to set Intel Speed Shift. I've also been poking at this and reading the fine docs but I also have other stuff to look at and do. . > > Yep. I also had to bisect this from what is now some 5 months ago :-( > > > > Diane > > -- > > - db@FreeBSD.org db@db.net http://www.db.net/~db > > -- - db@FreeBSD.org db@db.net http://www.db.net/~db