Received: by 10.213.65.68 with SMTP id h4csp340155imn; Tue, 13 Mar 2018 06:10:46 -0700 (PDT) X-Google-Smtp-Source: AG47ELstof02eZPcqxXRtPCPNKuhYNmAI3LC+27guT4VlNdEyLQPPDkbcghXJ/mzGNhPk1ZonFzs X-Received: by 2002:a17:902:6984:: with SMTP id l4-v6mr552917plk.61.1520946646727; Tue, 13 Mar 2018 06:10:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520946646; cv=none; d=google.com; s=arc-20160816; b=X6vcA+ycYgNOBDcYOx4a21XMPA2aZO4OSgq5/5rFInSJzV6L9SGK1RdRXK7KA8VDiH CXTrQlfOb8JaJSF/1JxzEYFbtYaZYCECdmBwS9zx0lLVMCaYkO2CsJGQmNlv03R7gwh2 kUcW33GkkY69pI6FwOfWsHgdksat/f8+iN2bFGtu4kjSOJewmEn88a4G/681hH8HqVdE PXswxwuR5cm1zdTG5W/BU+lpo9a5Xfm21N3lr9+h1Dn8Kaloo1/3zHvkqoAuSzNsHGT4 NycotWwYJTpEDg4ZKv9GE21T2fx+Bt3YRSkDxS9SmbmXpxf3xEBncGiThLgiY1vXCiDj AXRg== 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=yoqdddW9xWSnNjJhANTAAILCbAjOJbz63RFKZ7fFx/Q=; b=l592YO41eW8teoj8lmsQmY/FjxWM2PmnfWjRgwadF0gwD7VLf15TuXQOEBogVfg5Jh ZyuCkN+Nz5u+0vXhSuxppyECRY1QVQAtENBXFycrBF7E/IfLFJ1TZ8jcFZ0QMJw5eIz3 7h7vhMc1iAX4yNJ1WFJfAzbZaS5bxsA9Xp2As35PP0WHKfjS5DjqsX91eTKgRPaK71E6 pDIopA7fnOf/NiB0RyX4twPFGclLQNSZRot5ZgBAEegq4mGSeXA2qAWp/M90BDcu9HZx QKRpMIILP8wfz331HtoiNDxP3gxsFgJABbkl/esyrm6S0MiZvUKlQ4zdagas2xwidxIE 5yyw== 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 x1si110682pgp.89.2018.03.13.06.10.31; Tue, 13 Mar 2018 06:10:46 -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 S932354AbeCMNI1 convert rfc822-to-8bit (ORCPT + 99 others); Tue, 13 Mar 2018 09:08:27 -0400 Received: from mondschein.lichtvoll.de ([194.150.191.11]:57177 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751720AbeCMNIZ (ORCPT ); Tue, 13 Mar 2018 09:08:25 -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 1F6FA2BC437; Tue, 13 Mar 2018 14:08:24 +0100 (CET) From: Martin Steigerwald To: Hans de Goede Cc: Linux Kernel Mailing List , Thorsten Leemhuis , Tejun Heo , linux-block@vger.kernel.org, Ming Lei , Bart Van Assche Subject: Re: [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and could not connect to lvmetad at some boot attempts Date: Tue, 13 Mar 2018 14:08:23 +0100 Message-ID: <2276139.2HCKFmVDEL@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. Yes, I now good a photo of one of those boot failures I mentioned, at it seems to be related to blk-mq, as the backtrace contains "blk_mq_terminate_expired". I add the screenshot to my bug report. [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and boot failures with blk_mq_terminate_expired in backtrace https://bugzilla.kernel.org/show_bug.cgi?id=199077 Hans, I will test your LPM policy horkage for Crucial m500 patch at a later time. I first wanted to add the photo of the boot failure to the bug report. Ming and Bart, I added you to cc, cause I had to do with you about another blk-mq report, please feel free to adapt. Thanks, -- Martin