Received: by 10.213.65.68 with SMTP id h4csp911948imn; Wed, 14 Mar 2018 04:06:31 -0700 (PDT) X-Google-Smtp-Source: AG47ELvQ2fB2ssiR6FLjHkfDi8pjQACMurYiKvV41m/lQgVMA9DWnlbxeodzi0b5CThGSdQXbiij X-Received: by 10.167.131.199 with SMTP id j7mr3831049pfn.99.1521025591064; Wed, 14 Mar 2018 04:06:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521025591; cv=none; d=google.com; s=arc-20160816; b=UxLS0tDFw42XpRiLULU/jf7z1x6XNMrczvk5XY9vR/NXld24J7Lui26aAZaqSgCFeM ttF4vgoWIaEMBGmqbB3aOt3IBv5zyyfihvwfUPSgzdsjos2UYfL4Qbd71x6waurSvz/l lFUGWapK47dNyMFuVXj8sJOUOm3ZU26qqEnWPu7Q/XBWMtOe7ZOvIrHhU27AWSdJtAma UZbZI+5+Q1de1WekQMl5ldpcmmWcCJ487WMf4DM1J7fVqD//iwC7uPW/hGi4i38GyGLA gf2T5Q2SnYjjCwVl/chKJCpnyxmavgAXVq9nzUmcqUbsA05wpii+s//fZxZuYrODOv6U 80Iw== 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:arc-authentication-results; bh=7gGXpmWj5JQQU5PjWAD2hp4uRwQFwZcOcrV5bVNvzc8=; b=vigEzqS2T/zjC/shwc3Zd/GBMnkMeymXcjbd6IptRLfCb01ceqYE2bhZRKDt1xdI4V yqMcRSuMhoOH4B2DHvX59dVyh8pSfqrnZpIlQ7Eme+e7i7SCoMSDUD8q7z/MUD6oj9Zd 5nLyuafooxuul1oFg+JWlR5qhkAqiEcKHd+tVsRcLenrJO2TupyfN8D1O7Yft/wce9A2 MlBFpUqiIEDghVXvUsLY/BNLnx7POAkJcm6aw+AClERpdIk+Q9njrtWGQA3bq0GSDsIk rdNrFofXq8Si7+R75lKd8zmD3uhYtk0LyMrt5hEWCb4n7n0u/zo4GteEVEEjrpPEm6mT HJgw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t11-v6si1785577plr.411.2018.03.14.04.06.15; Wed, 14 Mar 2018 04:06:31 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751413AbeCNLFP (ORCPT + 99 others); Wed, 14 Mar 2018 07:05:15 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:38098 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751289AbeCNLFO (ORCPT ); Wed, 14 Mar 2018 07:05:14 -0400 Received: by mail-wm0-f66.google.com with SMTP id z9so3179917wmb.3 for ; Wed, 14 Mar 2018 04:05:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7gGXpmWj5JQQU5PjWAD2hp4uRwQFwZcOcrV5bVNvzc8=; b=l40a9tszbJJO6Fu0AzUkpcSR/WsBM/aT3xiv+mZyO4J/AGDl2BRHrfROqizt9SF6MH YC5Ubc7gI+ybPyFN6hwb3E04Sn6Oj0SK9M6tFsOYhfQi7gSsWK9nJRaxNC+0bGFdhnoj ED3CnZvAcFsymtJ/vnkDjqLj8+c5zfAYuj046jivaprMWeadSo4aGqdbPIewsRnKSF6J KRVwwX631M9TdC8bv9R8A4zKFrUYpRp1GH2liP5HoyBePxEfQ1afyITNXWeeue/Kzrfv xpDyvUZqCdzgkC7cBY4Jf5I2a9YwYbwkDm2LzvNgTIkMjJi+Qn7odKkvrL9bKfPfTP4x 4EuA== X-Gm-Message-State: AElRT7EyIkl0bx4kfqzasEC3qWJTdFlRtxe7dsCwWBlcl3DWruOu+703 u9SSSL6/IzfmJCYi+rNVvDDkTcpXkdw= X-Received: by 10.80.162.199 with SMTP id 65mr4452296edm.255.1521025513279; Wed, 14 Mar 2018 04:05:13 -0700 (PDT) Received: from shalem.localdomain (546A5441.cm-12-3b.dynamic.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id 33sm2036576edz.37.2018.03.14.04.05.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 04:05:12 -0700 (PDT) Subject: Re: [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and could not connect to lvmetad at some boot attempts To: Martin Steigerwald Cc: Linux Kernel Mailing List , Thorsten Leemhuis , Tejun Heo References: <27165802.vQ9JbjrmvU@merkaba> <3573548.kp1edD77Gq@merkaba> From: Hans de Goede Message-ID: <1e708e58-5ba7-8ce9-2edf-6cc7ba5f80c3@redhat.com> Date: Wed, 14 Mar 2018 12:05:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3573548.kp1edD77Gq@merkaba> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ? Regards, Hans