Received: by 10.213.65.68 with SMTP id h4csp966591imn; Wed, 14 Mar 2018 05:50:29 -0700 (PDT) X-Google-Smtp-Source: AG47ELvZBFev83ssjZRfoYWUh9D31B5HO924qIQNRjsM+EG39brdrVZfOlsvXmmq2oZkXcguiKy4 X-Received: by 10.167.131.29 with SMTP id t29mr4251164pfm.116.1521031829064; Wed, 14 Mar 2018 05:50:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521031829; cv=none; d=google.com; s=arc-20160816; b=HemltpscpsFjj9JNnRYeFi4R0tpba1U7Uvy6mr9xHX5CGaBAH6NQXusYpRyi8N85fN mvHKtmRxeKXoLJBF+F9yR1m5AZc+sVRKrz6m3IkzpzwkkA2LCA8Xsd9EOudvUFHL/pXF LP9mSoq5C2Tt3mSq4FiWrW9RK1BG0j82XwDxsH228++oYp3Ix7xM4FPvRKR3lK3U6AFZ 0nBTlR/eyPGMh3p3FK6luP27bmTbdWJUUucUXAh6qFjbA1gUGAl4NtzwxIFb0enf8klE Xa4LsVxFvs4cyt6u3cZ988nqPfkKOYVLwOEOn3K8Gnesdv/RDtp+CNC+ZnYbJID7BVB3 mbYQ== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=+3JpKhBiCfn9L6szAfIuE+MStKWYY5LlPqQvHcdd2i4=; b=xMO9pPLBCnCz5nfwjP5jq+LvdIhD74Yq9DMjpRiwZoA+ONPBu+NemFc8DHoSYvxgaM Ojdyv0SubwYEPzLY9JOCeCj4gerOA2cpSkaN7x4rcA97ZdVCwVv1h3oRqu2y8LSJIeMP MYZbiJaOqPLrRulSCFhOHgpq0lbSZIav+ZtAWS4U/sGdcd70wz5LVNmN6x7w2dDWYUM1 Q7E65xMsGi3T48ZOZZJYpJ+0FPIh0YYTA6vx9NvdLfTql4ik9LjV2A4KkonfLejLdAdK Huy8NUoX80KkGxgMDEDR1d1j0mcqs+p6lIy+a8LY/fGRezBLbRYCL/ZTa8+sNQq9EVRm QEbA== 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 f3-v6si1910605pld.200.2018.03.14.05.50.04; Wed, 14 Mar 2018 05:50:29 -0700 (PDT) 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 S1752018AbeCNMsy convert rfc822-to-8bit (ORCPT + 99 others); Wed, 14 Mar 2018 08:48:54 -0400 Received: from mondschein.lichtvoll.de ([194.150.191.11]:40807 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751401AbeCNMsw (ORCPT ); Wed, 14 Mar 2018 08:48:52 -0400 Received: from merkaba.localnet (unknown [91.221.105.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lichtvoll.de (Postfix) with ESMTPSA id 711D22BE997; Wed, 14 Mar 2018 13:48:51 +0100 (CET) From: Martin Steigerwald To: Hans de Goede Cc: Linux Kernel Mailing List , Thorsten Leemhuis , Tejun Heo Subject: Re: [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and could not connect to lvmetad at some boot attempts Date: Wed, 14 Mar 2018 13:48:51 +0100 Message-ID: <4373847.u3KAOBid1D@merkaba> In-Reply-To: <1e708e58-5ba7-8ce9-2edf-6cc7ba5f80c3@redhat.com> References: <27165802.vQ9JbjrmvU@merkaba> <3573548.kp1edD77Gq@merkaba> <1e708e58-5ba7-8ce9-2edf-6cc7ba5f80c3@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hans de Goede - 14.03.18, 12:05: > Hi, > > On 14-03-18 12:01, Martin Steigerwald wrote: > > Hans de Goede - 11.03.18, 15:37: > >> Hi Martin, > >> > >> On 11-03-18 09:20, Martin Steigerwald wrote: > >>> Hello. > >>> > >>> Since 4.16-rc4 (upgraded from 4.15.2 which worked) I have an issue > >>> with SMART checks occassionally failing like this: > >>> > >>> smartd[28017]: Device: /dev/sdb [SAT], is in SLEEP mode, suspending > >>> checks > >>> udisksd[24408]: Error performing housekeeping for drive > >>> /org/freedesktop/UDisks2/drives/INTEL_SSDSA2CW300G3_[…]: Error updating > >>> SMART data: Error sending ATA command CHECK POWER MODE: Unexpected sense > >>> data returned:#0120000: 0e 09 0c 00 00 00 ff 00 00 00 00 00 00 00 50 > >>> 00 ..............P.#0120010: 00 00 00 00 00 00 00 00 00 00 00 00 > >>> 00 > >>> 00 00 00 ................#012 (g-io-error-quark, 0) merkaba > >>> udisksd[24408]: Error performing housekeeping for drive > >>> /org/freedesktop/UDisks2/drives/Crucial_CT480M500SSD3_[…]: Error > >>> updating > >>> SMART dat a: Error sending ATA command CHECK POWER MODE: Unexpected > >>> sense > >>> data returned:#0120000: 01 00 1d 00 00 00 0e 09 0c 00 00 00 ff 00 00 > >>> 00 ................#0120010: 00 0 0 00 00 50 00 00 00 00 00 00 00 > >>> 00 00 00 00 ....P...........#012 (g-io-error-quark, 0) > >>> > >>> (Intel SSD is connected via SATA, Crucial via mSATA in a ThinkPad T520) > >>> > >>> However when I then check manually with smartctl -a | -x | -H the device > >>> reports SMART data just fine. > >>> > >>> As smartd correctly detects that device is in sleep mode, this may be an > >>> userspace issue in udisksd. > >>> > >>> Also at some boot attempts the boot hangs with a message like "could not > >>> connect to lvmetad, scanning manually for devices". I use BTRFS RAID 1 > >>> on to LVs (each on one of the SSDs). A configuration that requires a > >>> manual > >>> adaption to InitRAMFS in order to boot (basically vgchange -ay before > >>> btrfs device scan). > >>> > >>> I wonder whether that has to do with the new SATA LPM policy stuff, but > >>> as > >>> I had issues with > >>> > >>> 3 => Medium power with Device Initiated PM enabled > >>> > >>> (machine did not boot, which could also have been caused by me > >>> accidentally > >>> removing all TCP/IP network support in the kernel with that setting) > >>> > >>> I set it back to > >>> > >>> CONFIG_SATA_MOBILE_LPM_POLICY=0 > >>> > >>> (firmware settings) > >> > >> Right, so at that settings the LPM policy changes are effectively > >> disabled and cannot explain your SMART issues. > >> > >> Still I would like to zoom in on this part of your bug report, because > >> for Fedora 28 we are planning to ship with > >> CONFIG_SATA_MOBILE_LPM_POLICY=3 > >> and AFAIK Ubuntu has similar plans. > >> > >> I suspect that the issue you were seeing with > >> CONFIG_SATA_MOBILE_LPM_POLICY=3 were with the Crucial disk ? I've > >> attached > >> a patch for you to test, which disabled LPM for your model Crucial SSD > >> (but > >> keeps it on for the Intel disk) if you can confirm that with that patch > >> you > >> can run with > >> CONFIG_SATA_MOBILE_LPM_POLICY=3 without issues that would be great. > > > > With 4.16-rc5 with CONFIG_SATA_MOBILE_LPM_POLICY=3 the system successfully > > booted three times in a row. So feel free to add tested-by. > > Thanks. > > To be clear, you're talking about 4.16-rc5 with the patch I made to > blacklist the Crucial disk I assume, not just plain 4.16-rc5, right ? 4.16-rc5 with your 0001-libata-Apply-NOLPM-quirk-to-Crucial-M500-480GB-SSDs.patch patch. Thanks, -- Martin