Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1940757imm; Thu, 9 Aug 2018 04:50:25 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzeh0uJCgnP6CiukkQLm6W7obvMS1j2CSaP1Lu6toGqYRHDnerYkYr9gOw4xuAzJwRHFfEv X-Received: by 2002:a63:5815:: with SMTP id m21-v6mr1837493pgb.78.1533815425490; Thu, 09 Aug 2018 04:50:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533815425; cv=none; d=google.com; s=arc-20160816; b=EoYr06MtzoCgSPMykC9URHp4o/Cjr07gBNK0GwZbPJf2RTA/wx9SUWv46FZABxdBi8 jg4yIE1NZCbVZPs085cHKq/8FDFa+VOiNfOZTOMvjpkKAxFoTp2dpMK1IqBh95jCjsrK d1ofhB6MkveDrScFHCXB8GjrZAsAU/ZN+28vPzUxhH6P6lrbU/7uBBRJlZ/FIfjkQdJ0 hqCJOmYNLPeEuglaM7cDYi9NEp8BvYlJMWxD3SKZAvO8MTxRba/Ish3/g3pS9mrJrR8I Vr4OQTmVTJGc+AOV0w6DxlBZQTvkeCyIhYOAdKm6He9KY4AK8XYwnZ6jCNA1jszBjLS7 yfCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=1G2EoLBusoKPcFfwPUyFOvP7iXy6qrHOMmuP9VbYmhc=; b=pka3GoO6eHWUuna+L87ZNgtjdqexdtewEU5GO9DEuMqlK7KE17MvFnVpm71Ouv7lyF bKGjVXDGehEpdbpaAldhwhJKVrLZTjr88zMG4OZDlZlSsJlCAcXTY8KVqr2cz79v8Q+Q bq1SCLd9g2BPrAu/96DMy421l+G6D/0xiW2MFa+Ky1EPDOqiXV8vSFDA1DroSAlcVTwt giKYoCt+SBJyxDbOpAOuuT4U929K6STtdafwy3F0Pdu9LUCs+myhQfKevOHyQOF5a/dU GZGaG8KUJsHhR3h+o3d7iPvCnsbe6Af/KDnvJH8TuoN4hZRayJ86jk/JYvBlBva4MXWF WMWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qdWT+88S; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d62-v6si7774087pfd.334.2018.08.09.04.50.10; Thu, 09 Aug 2018 04:50:25 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qdWT+88S; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731001AbeHION2 (ORCPT + 99 others); Thu, 9 Aug 2018 10:13:28 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:34359 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727768AbeHION2 (ORCPT ); Thu, 9 Aug 2018 10:13:28 -0400 Received: by mail-wr1-f66.google.com with SMTP id c13-v6so4913962wrt.1; Thu, 09 Aug 2018 04:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=1G2EoLBusoKPcFfwPUyFOvP7iXy6qrHOMmuP9VbYmhc=; b=qdWT+88SLkVbR0IhS7mhz2A0OTNtBv+gIiA1VO8Hgh9et9MoMy3UWjHXMU0o+LJt9n f+1HjNd87CkcntJXi857ofELQ4qPV4LxKyyMX1q/R8SwHZV+DsreMU0k3Nves2SpPOZo 803gRdLhLcxkJMLJ+9FJ6r9gSFOkin95Uut2Bdx+r+P5OaLqsmFJ9hXQY7CaRfzEnHKX iSlZIM+qO0ZJK+PN+6n5hJoSWhfHPjhwZSvjLJ29Xe+aOxypVJehCZeJn3kUumM9pdsP 72DVb85S1biiNlhioO7WhXyWkipqDbYxEXY4FDLd2MLWMQ8PnDv8oadxm1cEXoWtmj2r 4BFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=1G2EoLBusoKPcFfwPUyFOvP7iXy6qrHOMmuP9VbYmhc=; b=I6NU+2j+MuKwXyzyey0V6zOLWmWaZjxsrjhL+cCYqJw2R0o5sqLTWPiRrylU6rFDpx fspnYC8SRBSml/S34NOG8hUsr6ad7zcfo7wn6+5EHctAAPF72vCagvJfLabKDDlHnJqS 9WKrYJz/5L/RrgHzeaHHaxgwKuQw5sPMQni1wmu+nxQY92S1PzqhzSTJI8RT0u58ZBw3 jNsMCMMcSdET4cfzF1NdRWfWblshD0g3Twh4h0pPTr5jCWW50Cn1gEZ2NIcmr7sBfhfm KjBVo1hftIvEeuwE842JtNatE+PHSYTFc3AxX4n7rUYA1DnYpR72G5aRTIy65DaASErx l67g== X-Gm-Message-State: AOUpUlECmkaLx8ndI8HMr+srhi3ZEyHQXYLwtVs/SnM+XBslxOjhtYgx 4NgWODkiuxi+wMOvtcQ/mEQRDqOa09E= X-Received: by 2002:adf:9142:: with SMTP id j60-v6mr1191913wrj.180.1533815334959; Thu, 09 Aug 2018 04:48:54 -0700 (PDT) Received: from pali ([2a02:2b88:2:1::5cc6:2f]) by smtp.gmail.com with ESMTPSA id j133-v6sm15708695wmd.12.2018.08.09.04.48.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Aug 2018 04:48:53 -0700 (PDT) Date: Thu, 9 Aug 2018 13:48:52 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Tejun Heo Cc: Robert Hancock , Jeff Garzik , Robert Hancock , "linux-ide@vger.kernel.org" , linux-kernel Subject: Re: linux: sata_nv: adma support Message-ID: <20180809114852.cwvyqeuilxv4qbsq@pali> References: <201412232051.07067@pali> <201508021108.52978@pali> <201508042006.57727@pali> <20180510135157.awgoymyr2p5vbmlq@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180510135157.awgoymyr2p5vbmlq@pali> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 10 May 2018 15:51:57 Pali Rohár wrote: > On Tuesday 04 August 2015 20:06:57 Pali Rohár wrote: > > On Monday 03 August 2015 05:02:15 Robert Hancock wrote: > > > On Sun, Aug 2, 2015 at 3:08 AM, Pali Rohár > > > wrote: > > > > On Sunday 02 August 2015 03:45:32 Robert Hancock wrote: > > > >> On Sat, Aug 1, 2015 at 2:09 PM, Pali Rohár > > > >> > > > >> wrote: > > > >> > On Thursday 25 December 2014 07:22:13 Robert Hancock wrote: > > > >> >> On Tue, Dec 23, 2014 at 1:51 PM, Pali Rohár > > > >> >> > > > >> >> > > > >> >> wrote: > > > >> >> > Hello, > > > >> >> > > > > >> >> > I have nvidia nforce4 motherboard with nvidia sata > > > >> >> > controller: > > > >> >> > > > > >> >> > 00:07.0 IDE interface [0101]: NVIDIA Corporation CK804 Serial > > > >> >> > ATA Controller [10de:0054] (rev f3) > > > >> >> > 00:08.0 IDE interface [0101]: NVIDIA Corporation CK804 Serial > > > >> >> > ATA Controller [10de:0055] (rev f3) > > > >> >> > > > > >> >> > I manually enabled adma mode (which is disabled by default) > > > >> >> > by adding sata_nv.adma=1 to grub cmdline. In git history I > > > >> >> > found that enabling adma mode includes NCQ support and > > > >> >> > reduced CPU overhead. It looks like adma mode is working, > > > >> >> > but at every boot I see one same error message in dmesg: > > > >> >> > > > > >> >> > [ 16.823514] ata1.00: exception Emask 0x1 SAct 0x0 SErr 0x0 > > > >> >> > action 0x0 > > > >> >> > [ 16.823520] ata1.00: CPB resp_flags 0x11: , CMD error > > > >> >> > [ 16.823524] ata1.00: failed command: SET FEATURES > > > >> >> > [ 16.823530] ata1.00: cmd > > > >> >> > ef/05:fe:00:00:00/00:00:00:00:00/40 tag 16 > > > >> >> > [ 16.823530] res > > > >> >> > 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error) > > > >> >> > [ 16.823533] ata1.00: status: { DRDY ERR } > > > >> >> > [ 16.823535] ata1.00: error: { ABRT } > > > >> >> > > > > >> >> > When adma is disabled then this error message is not > > > >> >> > generated. > > > >> >> > > > >> >> It looks like something is trying to issue a command to disable > > > >> >> APM power management on the drive, and the command fails > > > >> >> (likely because it doesn't support that command). I'm not sure > > > >> >> where that would be coming from - I'm pretty sure the kernel > > > >> >> doesn't issue that command itself. Something that's part of > > > >> >> your distro perhaps? > > > >> >> > > > >> >> I don't know why it would only be failing in ADMA mode either, > > > >> >> though depending on where the command is coming from, maybe > > > >> >> it's not being issued otherwise for some reason? > > > >> >> > > > >> >> > What does that error message means? It is critical? What is > > > >> >> > that command SET FEATURES doing? Are there any problems with > > > >> >> > adma mode on nforce4 motherboards? Because I did not see any > > > >> >> > problems (except that one error message). > > > >> >> > > > > >> >> > -- > > > >> >> > Pali Rohár > > > >> >> > pali.rohar@gmail.com > > > >> > > > > >> > Hello, > > > >> > > > > >> > now after long time I did more investigation and that error is > > > >> > reported for every connected HDD. I identified that it comes > > > >> > from udev script > > > >> > > > > >> > /lib/udev/rules.d/85-hdparm.rules > > > >> > > > > >> > which just call script /lib/udev/hdparm for every one connected > > > >> > HDD. > > > >> > > > > >> > Script /lib/udev/hdparm just call: > > > >> > /sbin/hdparm -B254 $DRIVE > > > >> > > > > >> > And that -B254 cause above error message in dmesg log. Output > > > >> > from > > > >> > > > > >> > hdparm is: > > > >> > /dev/sda: > > > >> > setting Advanced Power Management level to 0xfe (254) > > > >> > APM_level = not supported > > > >> > > > > >> > Any idea why in ADMA mode it cause above error (APM unsupported) > > > >> > and in non ADMA mode it is working fine? Maybe APM ATA commands > > > >> > should not be sent via ADMA? > > > >> > > > > >> > Here is another output: > > > >> > $ sudo hdparm -I /dev/sda | grep -i power > > > >> > > > > >> > * Power Management feature set > > > >> > > > > >> > Power-Up In Standby feature set > > > >> > > > > >> > * SET_FEATURES required to spinup after power up > > > >> > * Host-initiated interface power management > > > >> > > > >> The "set features" command is a non-data command so based on our > > > >> current knowledge, it should work in ADMA mode. However, these > > > >> NVIDIA SATAs are black boxes, and rather buggy ones at that, so > > > >> it's possible there's an unknown issue there. > > > > > > > > Maybe I should note that hdparm -I did not generated any error > > > > message. I post is here because it show "Power Management feature > > > > set" is supported by HDD. This indicate that HDD supports -B (APM) > > > > command, right? > > > > > > As far as I know, yes. > > > > > > >> The easiest way to test that would be to take out the condition > > > >> check for qc->tf.protocol == ATA_PROT_NODATA in > > > >> nv_adma_use_reg_mode in drivers/ata/sata_nv.c. That would force > > > >> it to disable ADMA for all non-data commands. > > > > > > > > Ok, as now I have just SSH access to that machine, I will do kernel > > > > patching later (when I have physical access to it). > > > > > > > >> I really don't know why Ubuntu is disabling APM on all drives on > > > >> bootup however. Especially for laptops, that seems like a silly > > > >> thing to do explicitly. Sounds like one of the silly things > > > >> Ubuntu is known to do without consulting people. > > > > > > > > Looks like this comes from upstream udev/systemd project :-( > > > > Anyway, for laptops on battery ubuntu has another set of scripts > > > > which turn on APM (based on connected/disconnected AC adapter). > > > > > > There's no such scripts in Fedora, so either they removed it, or it's > > > something that either Debian or Ubuntu has added in. > > > > > > > That udev script which turn off APM is called when any disk is > > > > attached to system (so at boot time it is called for every one > > > > disk). > > > > > > > > Now I just masked that udev script and it is no longer called... > > > > > > > > Anyway if I call hdparm -B /dev/sda I get output: > > > > > > > > APM_level = not supported > > > > > > > > And important is that there is no error message in dmesg. I get it > > > > only if I call hdparm -B with parameter (set option). But APM > > > > should be supported, right? > > > > > > Does the get command work without ADMA enabled? > > > > I requested to boot that machine with turned off ADMA. I verified it is > > turned off as I found sata_nv.adma=0 in /proc/cmdline and file > > /sys/module/sata_nv/parameters/adma contains big N. > > > > I called hdparm: > > > > $ sudo hdparm -B254 /dev/sda > > > > /dev/sda: > > setting Advanced Power Management level to 0xfe (254) > > HDIO_DRIVE_CMD failed: Input/output error > > APM_level = not supported > > > > It failed, but I do not see any error message in dmesg. There is nothing > > new in dmesg. > > > > So looks like I'm not able to set APM... But why in ADMA mode it > > generates some error and in non ADMA mode no error? Strange! > > > > Hi Robert! > > After long time I tested it again. I have there two SATA disks connected > to that computer. Running hdparm -B (without number) just print "not > supported" and hdparm -B254 still cause above kernel dmesg error. > > But second disk print via hdparm -B current APM level and via -B I > can set a new APM level. And it does not print any error (nor in dmesg > or on stdout). > > Therefore first disk probably does not support APM and above kernel > dmesg error is caused only when I'm trying to set APM level on disk > without APM support. > > So... is not this problem in kernel libata or sata_nv modules which > parses error messages for unsupported operations? Tejun, you are libata maintainer, can you look or check if this is a problem in kernel's libata? I guess that this is problem in propagating APM errors. At least disk without APM support should not cause such errors... -- Pali Rohár pali.rohar@gmail.com