Received: by 10.192.245.15 with SMTP id i15csp1229227imn; Sun, 11 Mar 2018 09:30:08 -0700 (PDT) X-Google-Smtp-Source: AG47ELvz/4kCl+5Nh/Zt8geI0Lu4syvAupVzFXPSniqKVO3JT8jq8uULuscGTu6/lxAD1Wu1PqwZ X-Received: by 10.99.117.6 with SMTP id q6mr4270697pgc.146.1520785808464; Sun, 11 Mar 2018 09:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520785808; cv=none; d=google.com; s=arc-20160816; b=LzXCuhiu3yI47TyPp+jbsSDw1KzuwSobRKwUKc/RXrpARFFU2kFa7CbnXZqvfjqXJy OFDfdrfXVFXylHGjvdJh6utw7LfeMUG7oQbzuE6/lOHDrlhFg7uyfihrr+hIxvY+dKPf OID/8a68AaCEIBrJBpR29g7GADevVZGtJnuYLKQYQRUbpwTlZTquAphTTH1j20AFVAGO k4IcIrRkXTX+O9Yp1TqwKZWdI9Mj9896OC+rNxPsXqrDnxMB+UUCA4vAzvb1FoVWg6rV RGMbjb3MPD1RS5HiatnT+sx3nN9egkppFB9Ov9kcWyKRxZy3Dmfs6Uwvz6owa8Xq4M3Q dEpA== 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=3PAIMeAVSiBKgOrGnVfpUG07qFwIJRrmAZQOxw8gLuU=; b=AkxNvQS0YdFLr3EKJkulj7/pEl0JKVGHAeg2cNj1v4SU08YI7yOE/UDGD15aYXgmtC fiBl+VnLU/GmZyERqG1uekAE/ogbgC3b8UO5fuR7Ac5INpFxpS3YqZapyvfzIwQ0vq6T QQxHOeU04US3AHSOsKbIIwvUZKztfPoR2e3xPqcUWfDSQeW7b8FdnoREPhiuWD1Bp33K xBhwixUGXw2Ctm251tUvr+0MJIEBBMCz2EeivhADJVaZnwxP2iqO7Qvm4kDiIZ6FVXWh HsaQgkCDG1/hGgTtHHRYdOUbMYAnTmLhqW/t4xA8sNLCJz6/x66qEd+qjNe+bqdwzQV8 VSqg== 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 e9-v6si4612944pln.492.2018.03.11.09.29.54; Sun, 11 Mar 2018 09:30:08 -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 S932241AbeCKQ2b convert rfc822-to-8bit (ORCPT + 99 others); Sun, 11 Mar 2018 12:28:31 -0400 Received: from mondschein.lichtvoll.de ([194.150.191.11]:32817 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932136AbeCKQ2a (ORCPT ); Sun, 11 Mar 2018 12:28:30 -0400 Received: from merkaba.localnet (ppp-46-244-253-115.dynamic.mnet-online.de [46.244.253.115]) (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 DAD6E2B8B91; Sun, 11 Mar 2018 17:28:28 +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: Sun, 11 Mar 2018 17:28:28 +0100 Message-ID: <6020448.5HgvTYnRh2@merkaba> In-Reply-To: References: <27165802.vQ9JbjrmvU@merkaba> 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 - 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. I think I can do that during the week with 4.16-rc5 then. Is it possible to override that setting at boot time with a kernel parameter? It would make it easier to switch between the policies for testing. I didn´t see anything regarding that in the help of the kernel option. Thanks, -- Martin