From owner-freebsd-current@freebsd.org Mon Jul 1 16:11:41 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32FFD15DE98C for ; Mon, 1 Jul 2019 16:11:41 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4297585B75 for ; Mon, 1 Jul 2019 16:11:40 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f174.google.com with SMTP id m23so13775063lje.12 for ; Mon, 01 Jul 2019 09:11:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=iI0cMSa8XCraRBocxpghERzHsLWaXuVFjlTPsJDP4BY=; b=Q1GFUjxq2QDdByLAPpDoNErcdsl4keM7w8Twq9dIYTNtZFpknssN0e6AMLzkXbFW6t 6nrD9NMcaMZ5dCsWRg9g6Yjj0ip7ewoSgH/UU0GdMq7kRQXkr+06OLAOdgRkZhi2k4Uq YE4WOYTSUBy/v4/T+TGnL8h6djTZbTr1nWgpxxStdjrGVgm6f2lZVhlJZcmjUKdTs9to EJul5UuoLB2WwweKQzphflP/54Sr6eAmayJNHYaWOg3pWOjYT7EH/8WfKZfxb6JoejSi xX/zWK1c9uLSFnT3jzjLdfANp1owKobuvQM7skkjOC2cTryBo2/r85DMEd8Vkc4vXjX1 lZUw== X-Gm-Message-State: APjAAAUYyp3n3sWjYkpCjZmuXQ56lfloF63tCq+CvaNIQ2lO4i0m28EM wiJrckCRp+Nig6pirohdemY9ggkG/X0= X-Google-Smtp-Source: APXvYqzoGm4C4uPLuM5EbtrCyy/ztk0Nty9vURM7rDKqQTP3FEa+IZa5rQBZpVo1hOddUDhZiDvdwQ== X-Received: by 2002:a2e:8613:: with SMTP id a19mr14131213lji.163.1561997037440; Mon, 01 Jul 2019 09:03:57 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id g5sm3310100ljj.69.2019.07.01.09.03.55 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jul 2019 09:03:56 -0700 (PDT) To: FreeBSD Current From: Andriy Gapon Subject: i2c bit banging timeout for SCL Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Mon, 1 Jul 2019 19:03:55 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4297585B75 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.174 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.11 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.82)[-0.824,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.28)[ip: (-0.53), ipnet: 209.85.128.0/17(-3.45), asn: 15169(-2.34), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[174.208.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 16:11:41 -0000 iicbb driver has a hardcoded timeout that defines how long the driver waits for SCL line to go high after the driver releases it to float. Sometimes slaves hold the line low until they are ready to continue with the communication. As a side note, the timeout means that the driver just goes on as if the line became high. Maybe it should produce an error instead. Anyway, I would like to increase the current timeout of 100 x 10us to 1000 x 10us. The rationale is that there are many slave devices, like sensors, that take about 10 ms to return a result. So, I think that it makes sense to play nice with such devices by default. Probably I'll add a sysctl for that parameter while I'll be there. Any objections? -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Jul 1 16:16:42 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72B0415DEDAA for ; Mon, 1 Jul 2019 16:16:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9D086064; Mon, 1 Jul 2019 16:16:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id B190A2025622; Mon, 1 Jul 2019 16:16:33 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x61GGX1m092908 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 1 Jul 2019 16:16:33 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x61GGXis092907; Mon, 1 Jul 2019 16:16:33 GMT (envelope-from phk) To: Andriy Gapon cc: FreeBSD Current Subject: Re: i2c bit banging timeout for SCL In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92905.1561997793.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 01 Jul 2019 16:16:33 +0000 Message-ID: <92906.1561997793@critter.freebsd.dk> X-Rspamd-Queue-Id: 5B9D086064 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.08 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.950,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.91)[0.911,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(0.06)[ip: (0.11), ipnet: 130.225.0.0/16(0.05), asn: 1835(0.15), country: EU(-0.00)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[phk.freebsd.dk]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.87)[0.866,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 16:16:42 -0000 -------- In message , Andriy Gapo= n writes: >iicbb driver has a hardcoded timeout that defines how long the driver wai= ts for > SCL line to go high after the driver releases it to float. Sometimes sl= aves >hold the line low until they are ready to continue with the communication= . >As a side note, the timeout means that the driver just goes on as if the = line >became high. Maybe it should produce an error instead. > >Anyway, I would like to increase the current timeout of 100 x 10us to 100= 0 x >10us. The rationale is that there are many slave devices, like sensors, = that >take about 10 ms to return a result. So, I think that it makes sense to = play >nice with such devices by default. > >Probably I'll add a sysctl for that parameter while I'll be there. sysctl or ioctl ? -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Mon Jul 1 16:19:09 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3866A15DEEFD for ; Mon, 1 Jul 2019 16:19:09 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43C6E8621C for ; Mon, 1 Jul 2019 16:19:08 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f181.google.com with SMTP id a21so13820849ljh.7 for ; Mon, 01 Jul 2019 09:19:08 -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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sz+B10z1jqGAZctQ3Bz47K0f2l/ta6//9fq6MArDZFA=; b=IuuYetkv9p8sw+EMLu+nFHumdj9h0ZdrLc8Os2diFLs8uplfMIX7KYErEyCn6StXCV 6fnDxYLAlJEHiFbfwCSs6aes1Kac7keb14wf0n5cW7oy+e8qv+sjTNOtEMVjGwBaEre2 +7Hcntf+RIWHCrrnAdxG00Dyd+piDRelhrR/bOrGh2Lqy8Ca6y9+3yxYX1nnUgkjtJ/G LRZwLokXl+XDq3bqPPshHLUB+azhnysCDrLiM8QxEXFt+lpxCHdI8iEpwm203ki9VL31 W7CJN2E29QZctm/4LQO5DNin6SCDe4b1iKScy02ATehGErYBASxTmFE9PSKMW2+4RX1Y TE0g== X-Gm-Message-State: APjAAAUFSvZRnpLeXAVQFVt0q7IMWJSRZcTK3UH2r/IPLf7Thq8eb43Y i2BL3bPUbVHwMbgRkMyT2ss+MNay4Lw= X-Google-Smtp-Source: APXvYqwUoKYymUZkSCt2ofH3nt/DwC89rglOhY9r8DBEty0eTHCSySan+njU4NKcaEuhfjpYng+E8g== X-Received: by 2002:a2e:9192:: with SMTP id f18mr14727688ljg.52.1561997940925; Mon, 01 Jul 2019 09:19:00 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id z6sm2801489lfa.45.2019.07.01.09.19.00 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jul 2019 09:19:00 -0700 (PDT) Subject: Re: i2c bit banging timeout for SCL To: Poul-Henning Kamp Cc: FreeBSD Current References: <92906.1561997793@critter.freebsd.dk> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <219f9907-5e66-018e-4fd5-550e522b1ecf@FreeBSD.org> Date: Mon, 1 Jul 2019 19:18:59 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <92906.1561997793@critter.freebsd.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 43C6E8621C X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.17 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; IP_SCORE(-1.28)[ip: (-0.54), ipnet: 209.85.128.0/17(-3.45), asn: 15169(-2.34), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[181.208.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.88)[-0.879,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 16:19:09 -0000 On 01/07/2019 19:16, Poul-Henning Kamp wrote: > -------- > In message , Andriy Gapon writes: > >> iicbb driver has a hardcoded timeout that defines how long the driver waits for >> SCL line to go high after the driver releases it to float. Sometimes slaves >> hold the line low until they are ready to continue with the communication. >> As a side note, the timeout means that the driver just goes on as if the line >> became high. Maybe it should produce an error instead. >> >> Anyway, I would like to increase the current timeout of 100 x 10us to 1000 x >> 10us. The rationale is that there are many slave devices, like sensors, that >> take about 10 ms to return a result. So, I think that it makes sense to play >> nice with such devices by default. >> >> Probably I'll add a sysctl for that parameter while I'll be there. > > sysctl or ioctl ? An ioctl that could set the value per slave sounds like a very good idea. But it's a little bit more work than I planned for now, so it's a sysctl to set the default global value. -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Jul 1 16:27:53 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CEC115DF43F for ; Mon, 1 Jul 2019 16:27:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 651DB86AB1 for ; Mon, 1 Jul 2019 16:27:52 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1561998465; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=n6/OfOEa6AhCFJ9GFhyfcJdZ+cehIHtsANwxYinoNqwvK7bw8Tzx6kfr2QseKBbdpb16euPx2RA18 JQGMKCKrz/Fx8AU1YhDsbVYUzWcXNi0qoXki3i20XhmzQ5r55MHsfmp9a9vbr/E1gW3w4WJFmfMfsQ 9ce2bbMe48AN8JYNUZvYiG9hM2FmpF1c8lWC2ep1pe/Pqcv/7oa6SF9Segd/UxJt62zq1IJQ4rA+ns F0IfAhdGYEzYMV35vIpP3m3YpA7R50mYHzcaSxvm3tbzWPNqeLRhxycErEQl4+atrFXUN/ZYg3Lgg3 VYn16ndm+4snbXkrk1tJLQ48QIRStSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=8ExaAHfbZ53cCLGbs8mYIV+sUHN4aUnNM51NEtpgRaY=; b=uC4xB4tMVPHGlQdJGNRSv8eo/wBwRYvBFkBV07ABpf10EHDAq69ookcwMg759yn50B/+Lu0mkcg/O IZ2gyw5i9gjDZHxGOOwNivsvXhSyGdJ1rpPlw7fjjXOuXbaMF0CrI7vTjRKWnAnwKCP5nsHRgvc3CI SpJVljCd4qvFQbZPIM4G8ntevB21kzUG8DHknAAyXY8yiCWkDJztaStkEZWvfh4KmtcMKVihZh7tY4 bIwbmhz0ypTJV0DDa8RU9wNjjZlQ98zSWm1Q+1CbALmbxRP7vIcgthkje3RvLnSWsBR7hs05FbFOKn d+5jDUK3hSuqRMUqW53xoPw07vD9q2Q== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=8ExaAHfbZ53cCLGbs8mYIV+sUHN4aUnNM51NEtpgRaY=; b=SDyK9DHmOvJ/1vXyngUetK3cyFbgSL1bhp0O4l3rkN7nYAoo0ix2wVBsoOxdWdqZ9JwDgZdE5m/Lj BVwKTy0v8+OgJI2OKCi+eKSPogRTFvIQLCAlTRJmD/JyLpMGXoiQd0BrvlAClz5JMRAdtXT/ZuBgay ZkhCaYMhkywRIh7MuJ13G23WlYIPvtCG+Uj95Adbxn6qQxn3ICcgVQ2SrnTm2txXoqe/qgNjcKnu47 2Fu85vPiXud5aTODykoqnAteS/Rb6nr6P92zc4osjWk//qAdbOzswdC9MnQ1Rem+8h01Dl/LTR8T9c JRS+n5k1+tSDOukUtZPdANw3jqaDNpw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 2676aacc-9c1d-11e9-939f-ed46564da17d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 2676aacc-9c1d-11e9-939f-ed46564da17d; Mon, 01 Jul 2019 16:27:43 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x61GRgSv074903; Mon, 1 Jul 2019 10:27:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <7e5d8a06bc2d46263262369464e9348b82263847.camel@freebsd.org> Subject: Re: i2c bit banging timeout for SCL From: Ian Lepore To: Andriy Gapon , FreeBSD Current Date: Mon, 01 Jul 2019 10:27:42 -0600 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 651DB86AB1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-3.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 16:27:53 -0000 On Mon, 2019-07-01 at 19:03 +0300, Andriy Gapon wrote: > iicbb driver has a hardcoded timeout that defines how long the driver waits for > SCL line to go high after the driver releases it to float. Sometimes slaves > hold the line low until they are ready to continue with the communication. > As a side note, the timeout means that the driver just goes on as if the line > became high. Maybe it should produce an error instead. > > Anyway, I would like to increase the current timeout of 100 x 10us to 1000 x > 10us. The rationale is that there are many slave devices, like sensors, that > take about 10 ms to return a result. So, I think that it makes sense to play > nice with such devices by default. > > Probably I'll add a sysctl for that parameter while I'll be there. > > Any objections? Many (perhaps most?) modern i2c slave devices are both i2c and smbus compatible, and the smbus slave timeout is 35ms, so that wouldn't be a bad default value. I don't think ignoring the error and forging ahead is a good idea. It should return an error, and perhaps it should use the bitbang bus- recovery sequence (from iic_recover_bus.c) to unwedge the slave device. -- Ian From owner-freebsd-current@freebsd.org Mon Jul 1 17:07:10 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E99AC15DFF20 for ; Mon, 1 Jul 2019 17:07:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF23A87E3D for ; Mon, 1 Jul 2019 17:07:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82f.google.com with SMTP id p15so15441175qtl.3 for ; Mon, 01 Jul 2019 10:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ZD2al5pF60lGHyVcmdHGx1qQDa093W47yPaszmMruE=; b=De9yNNo9Mv2+Lb9qAt0KSxAknkUZ1VTW6BKqMN8ZdyUwohNhhuDk+NoD9lFjg8CRCQ LNprmmtHsKc8d0oRzkdl8ebuLjluzGPNEwngY5/9GT1Dp0vvw/0C/M1WL1chd/+5Yks2 7hFUKyjKR2Xbd/dbMaoSKzb6EUaGiAQvgP3JYGy5BL07cJYZqUnw8wYtN8bjwRtKe8gb dGkLnuEa8hFUXnK5x7UNYATssm9UlW8ZcXPA+h7El1PWOoTaNtMlsfIzeMVh81/q+gd+ U+0pD52ZwJDUKyooQZfVUWBQDcvoM4Mky85g3YBZkhWty2TUB0zfXT2c071OmyCzyr2i PIqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ZD2al5pF60lGHyVcmdHGx1qQDa093W47yPaszmMruE=; b=idHDezSqJBMa2Nabdr21hVWhO1xnWH61/aA2igJ8UlCFfHaF3SEkLhHF5YkxS17zdd v97tmUpT94BLNUlzZD8SeXEss7Ic9oHSlTHUJ00JTdd+ilf0DuIaKI0I5ahwDqhTs3Ck IZBGx0ue+I9AL1YxkWKVA6t5Z1G0j49mzDqbjmi3kGer+wpY9qtKmvDbWIEoGvl+UYDF FfAQdsYsACfyEYVgb+Ei+gJQOkTE1NjALNc2hnrt0qfkuo2BnRkJ6IXZKwU0QoE2KU7H MNOeht3m6QwWLElpMRN0yOZ4knN7q2mxw3NL6Bd55Z/pvtr4yHNhUJRioHxWs0Q+DsBt coEg== X-Gm-Message-State: APjAAAUQqc41ds4Vuf3byF5odAzV+2/5zc80k8AoM9eZYhxgY9ak3I9a K6zLwLI8GD8YpDXEi06RZXWQEhUCXyNUg7BiYxW57Q== X-Google-Smtp-Source: APXvYqzfIxOrh9yMXUaazzPqyxk84dddF7wHXG4i4ULMNcvqCwYw2vWIQkcu+PYkro42+ZKMggMYQWw31Pw6nITPOtE= X-Received: by 2002:ac8:2baa:: with SMTP id m39mr21703250qtm.242.1562000827998; Mon, 01 Jul 2019 10:07:07 -0700 (PDT) MIME-Version: 1.0 References: <7e5d8a06bc2d46263262369464e9348b82263847.camel@freebsd.org> In-Reply-To: <7e5d8a06bc2d46263262369464e9348b82263847.camel@freebsd.org> From: Warner Losh Date: Mon, 1 Jul 2019 11:06:57 -0600 Message-ID: Subject: Re: i2c bit banging timeout for SCL To: Ian Lepore Cc: Andriy Gapon , FreeBSD Current X-Rspamd-Queue-Id: BF23A87E3D X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=De9yNNo9 X-Spamd-Result: default: False [-5.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[f.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.89)[-0.890,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.99)[ip: (-9.41), ipnet: 2607:f8b0::/32(-3.13), asn: 15169(-2.34), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 17:07:10 -0000 On Mon, Jul 1, 2019 at 10:30 AM Ian Lepore wrote: > On Mon, 2019-07-01 at 19:03 +0300, Andriy Gapon wrote: > > iicbb driver has a hardcoded timeout that defines how long the driver > waits for > > SCL line to go high after the driver releases it to float. Sometimes > slaves > > hold the line low until they are ready to continue with the > communication. > > As a side note, the timeout means that the driver just goes on as if the > line > > became high. Maybe it should produce an error instead. > > > > Anyway, I would like to increase the current timeout of 100 x 10us to > 1000 x > > 10us. The rationale is that there are many slave devices, like sensors, > that > > take about 10 ms to return a result. So, I think that it makes sense to > play > > nice with such devices by default. > > > > Probably I'll add a sysctl for that parameter while I'll be there. > > > > Any objections? > > Many (perhaps most?) modern i2c slave devices are both i2c and smbus > compatible, and the smbus slave timeout is 35ms, so that wouldn't be a > bad default value. > I'd concur here. Someone else will have a device that takes 20ms to reply and wonder why we're broken... The only issue, really, is that this timeout is a busy loop and there may be I/O bus contention introduced on these systems. My gut tells me that we should look out for that, but bump the default timeout to the limit of the spec we implement. There's no I2C limit, and there is a smbus one, so let's go with the latter. Most of the time, most of the devices will react within a millisecond anyway, which isn't terrible for a bit-banged situation. > I don't think ignoring the error and forging ahead is a good idea. It > should return an error, and perhaps it should use the bitbang bus- > recovery sequence (from iic_recover_bus.c) to unwedge the slave device. > Also agreed. Warner From owner-freebsd-current@freebsd.org Mon Jul 1 17:14:51 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90D8215E0230 for ; Mon, 1 Jul 2019 17:14:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B0197882C1; Mon, 1 Jul 2019 17:14:50 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id C05A52025629; Mon, 1 Jul 2019 17:14:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x61HEnIn093150 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 1 Jul 2019 17:14:49 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x61HEmK9093149; Mon, 1 Jul 2019 17:14:48 GMT (envelope-from phk) To: Warner Losh cc: Ian Lepore , Andriy Gapon , FreeBSD Current Subject: Re: i2c bit banging timeout for SCL In-reply-to: From: "Poul-Henning Kamp" References: <7e5d8a06bc2d46263262369464e9348b82263847.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93147.1562001288.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 01 Jul 2019 17:14:48 +0000 Message-ID: <93148.1562001288@critter.freebsd.dk> X-Rspamd-Queue-Id: B0197882C1 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.95 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.82)[0.821,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.89)[0.893,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: phk.freebsd.dk]; NEURAL_SPAM_LONG(0.88)[0.883,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; IP_SCORE(0.06)[ip: (0.11), ipnet: 130.225.0.0/16(0.05), asn: 1835(0.15), country: EU(-0.00)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 17:14:51 -0000 -------- In message , Warner Losh writes: >The only issue, really, is that this timeout is a busy loop and there may >be I/O bus contention introduced on these systems. Does it have to be a busy loop for the entire duration ? Spin for the median, timeout+poll for the rest of the time ? -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Mon Jul 1 17:25:24 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E4C115E05CF for ; Mon, 1 Jul 2019 17:25:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB0FA887DA for ; Mon, 1 Jul 2019 17:25:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82f.google.com with SMTP id d17so15475972qtj.8 for ; Mon, 01 Jul 2019 10:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DWM+Ut0P/19uItBIedLKgTD94iOmE4mKo+jkd4URvhY=; b=bQlwOJ+0ZRxFF1ArT40yodEGYCiSTzUQVygo/bOoGoPcvbXJili3pc1Gwj1hOZ4T69 1kigexTo5+RU5b4U9fphDwu0aaOObkSajpOvuyd53hpw11f79l4+Aspx//ktmRDjJsvf IlsCPUMC92QwRfyBllYXpOxwaieW6Ov7viKz/mJnNAyt/FzDSqgyR97WIu1fzBVn35hk Kjxt/hcoEAyjcy179GbVop4kJ9D9vEfop4g6PhCMuFh7zkauxGH47bNttskvWLuBBAcR f1lFaOYHyZPnWGruVsYyzHQw+ILGuU3A2D5rmgTycJ4wbnjCtbE6MXFhod4WB4hGO1iM TkCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DWM+Ut0P/19uItBIedLKgTD94iOmE4mKo+jkd4URvhY=; b=dKQw2GpqYqGpIeaPm7EdfzvFmY/nGyBs3jB2jr99Jhft9PnudmwI0k2c/veuGHTyMf eHm36+o85fylsU+SkTHmwmBniL1R7y+fGp7zriIP/LssPOy6W0IKNb92LNwJY1FIzUJW XyAXdGYYxlmDUCkt1fD11Zpftxdqjx1tfX53QUGl4hF/8Z6g3upGgg54FnVR31Slk+lA nT6mpiGSMgPkJbrgFH9peN43ACElUPT9m6AuJbQAh0YW/ROAKDc/stxdzrmJbi+xiU/z 88zGzseLA8C3WWJ0miGV+irx4doHFSd/Yj6jlCpKGeg6p4b1D/VIryZj2z4troDqaSbW wFsw== X-Gm-Message-State: APjAAAXzVHUiPIy6KEnJpfYH8dlLBDlhtIbPPXEbdyFWd4JC/G9I7kac xSuHE92wawofvd85v3vyMXQNTxkPBv/K0V9A7Z0YLA== X-Google-Smtp-Source: APXvYqyFNHESqmXU7QAeK8bjm2I3zOFgIY2d7YOYEkANgrizRJ5I8BzLf2VtGzJpsxUsdA1wG9er02xFu4b4KOHL6og= X-Received: by 2002:ac8:2baa:: with SMTP id m39mr21780875qtm.242.1562001923324; Mon, 01 Jul 2019 10:25:23 -0700 (PDT) MIME-Version: 1.0 References: <7e5d8a06bc2d46263262369464e9348b82263847.camel@freebsd.org> <93148.1562001288@critter.freebsd.dk> In-Reply-To: <93148.1562001288@critter.freebsd.dk> From: Warner Losh Date: Mon, 1 Jul 2019 11:25:12 -0600 Message-ID: Subject: Re: i2c bit banging timeout for SCL To: Poul-Henning Kamp Cc: Ian Lepore , Andriy Gapon , FreeBSD Current X-Rspamd-Queue-Id: EB0FA887DA X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=bQlwOJ+0 X-Spamd-Result: default: False [-5.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[f.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.89)[-0.886,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.99)[ip: (-9.40), ipnet: 2607:f8b0::/32(-3.13), asn: 15169(-2.34), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 17:25:24 -0000 On Mon, Jul 1, 2019 at 11:14 AM Poul-Henning Kamp wrote: > -------- > In message < > CANCZdfoFBvmxPtnEL4GOqXTvp6Zd-xrtja4rmUO1rAcy0JdeSw@mail.gmail.com>, > Warner Losh writes: > > >The only issue, really, is that this timeout is a busy loop and there may > >be I/O bus contention introduced on these systems. > > Does it have to be a busy loop for the entire duration ? > > Spin for the median, timeout+poll for the rest of the time ? > That's a good suggestion. I'd be inclined to spin for 1 tick or so, then do a timeout per tick after that (eg, shift from DELAY to pause(1)). It won't be super accurate or high performance, but when the devices are slow, that would add only a little extra time. Ideally, that's what we'd do. In the short term, bumping the timeout wouldn't be horrible. Warner From owner-freebsd-current@freebsd.org Mon Jul 1 17:41:23 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB8C915E0B8B for ; Mon, 1 Jul 2019 17:41:23 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15366891AA for ; Mon, 1 Jul 2019 17:41:22 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1562002876; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=fqOa+foTKjVmMfw1xNyHzVDQW2Fa3o1IkYCMeR1AEy26PGFLcuFFc7H8Q46gkTecI2pzY6ip82Lvy Of1OMOHc8fl2ObcRsmy/6H8OxSduCHnG5K2amwhpB4NRzu7l68GIAj0O+AhnUlr3SXeA57XCyIFeJ1 tD5tWVjE3GiEraWLAli8rHfxH9jBp/n7cAoWP1bkMeQbbzxvBBP1jq/rBJ4apiwFUU7Zs9yJwQ1Dal b7iZcQ+RKGT952epWBoLJSa8ShxjEjq70vKm9e3zJXAQsuasMhi4mJhzfo5vaM1YhUxtZkhTN+y1sY Lmic8SdOcgpBKMLr/+OiaBx151X8V8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=Xkf/MkDTZX/qO6EtHE3mRRlNSr88iI8nRb9by0EHOZE=; b=oZeO/QMOFRLhB0xJUr7u6nATyYdXJEPR0Ndc45R9QR48937/iEyx0UulFd/WMYcSuHXVxlvDjx3CD gJUQbl2Nfqs9EDOnoflBOfFesoi0O3QONQNOy2DYIrXBD6YtA+fUXdgVfaefbF2Mmpn3RaOg7DqoCT 60C5eTJw75v4OabcVW85m9UzbbCpNkcdqhvQaLkuj2io0PnaDkyNA+6BBkbMacI+zdjJF5yDasw/37 A06YB+rHcFyFa/dcW+dGQRw+3c7bxaBMwmDmU1mZo7bzmBKvVJc1Un/oB/PBntXABJaX+oAVOyIvtM xdOYUCqbTyUt5PGqCkShrnXYNTogz0A== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=Xkf/MkDTZX/qO6EtHE3mRRlNSr88iI8nRb9by0EHOZE=; b=d8s6S7lljPG8cal2m3GvZLDLJOTt8U8GTxQQ1xo4DxVvsJXHiDo3+26NdcThjsElYWqop2xvWRDWS ypaWjzEw+fT/escVjUOxn27r5oJy6QyzHb9dOY2Ve+Qt22t5RU99h7RF+BkP9RYRu4RXHYRRhFG5H+ oyWdGE9uVmhY0nXmlXJ1QXWQiJonM4R6XFlOFBTrSY81iAVZR8ZNZ3W3v9XD9yUfB0w82FGK99tVEb HPdVE/H71BDee06rSQtVx9TTv9KHPG8lAIPcDgBDwyO7IBQSjtTtJQPSPLfxKougO4cMk1Jkpmwepo Ej3nQZxJUC9xipK6d6jGchkMfSvovvA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 6b295fcf-9c27-11e9-90d7-2f7ae9aadc99 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 6b295fcf-9c27-11e9-90d7-2f7ae9aadc99; Mon, 01 Jul 2019 17:41:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x61HfCmf075111; Mon, 1 Jul 2019 11:41:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <291f26bcc4b4b30cda4f5b23855e889aa5883ee3.camel@freebsd.org> Subject: Re: i2c bit banging timeout for SCL From: Ian Lepore To: Warner Losh , Poul-Henning Kamp Cc: Andriy Gapon , FreeBSD Current Date: Mon, 01 Jul 2019 11:41:12 -0600 In-Reply-To: References: <7e5d8a06bc2d46263262369464e9348b82263847.camel@freebsd.org> <93148.1562001288@critter.freebsd.dk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 15366891AA X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 17:41:24 -0000 On Mon, 2019-07-01 at 11:25 -0600, Warner Losh wrote: > On Mon, Jul 1, 2019 at 11:14 AM Poul-Henning Kamp > > wrote: > > > -------- > > In message < > > CANCZdfoFBvmxPtnEL4GOqXTvp6Zd-xrtja4rmUO1rAcy0JdeSw@mail.gmail.com> > > , > > Warner Losh writes: > > > > > The only issue, really, is that this timeout is a busy loop and > > > there may > > > be I/O bus contention introduced on these systems. > > > > Does it have to be a busy loop for the entire duration ? > > > > Spin for the median, timeout+poll for the rest of the time ? > > > > That's a good suggestion. I'd be inclined to spin for 1 tick or so, > then do > a timeout per tick after that (eg, shift from DELAY to pause(1)). It > won't > be super accurate or high performance, but when the devices are slow, > that > would add only a little extra time. > > Ideally, that's what we'd do. In the short term, bumping the timeout > wouldn't be horrible. > > Warner Most of the DELAY() in i2c bitbang is just the idle time before toggling the clock line to achieve the 100khz bus rate. That's a 10us delay, and on modern hardware those delays should be pause() calls because that's enough time to get useful work done. When polling for ack at the end of a byte, using a DELAY(1) loop makes more sense (actually, just polling without delay may make even more sense, since DELAY() is generally just polling a clock register). Hmm, actually, it looks like iicbb hardcodes the bus frequency delay as 10us and delays after every toggle, so I guess it's really running the bus at 50khz. -- Ian From owner-freebsd-current@freebsd.org Mon Jul 1 20:17:03 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A67AB15E3555; Mon, 1 Jul 2019 20:17:03 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B77D8E31C; Mon, 1 Jul 2019 20:17:02 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm1-x330.google.com with SMTP id s3so758584wms.2; Mon, 01 Jul 2019 13:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=3093sPFniKdvfBvTjD0OIzJq6EL6GR0Xt2s6E5hxDBw=; b=WdUdy5QY1SEGzXDabFsnCd7+neHF/NRbrAuNMnGm+zXnS+xbdWHWYrAOpXRubAjlfs arAoGRNa4E+75blnws21HbWqV0Jo+j8xPSIR8zYz/Hv5KzEV8R6ERfZsxkLs6upPtqqv WN0pXvbigAJGXFQyD3hVYADaNcvMAqo1dMBu55/iEhZHWjdknkxKsWCeDnaAtxcVej1u SbP6M9MloUaWVPrGrWrMDx8olspjWmHmBxdEmraOQ/xT6avJd3PKIAVvx9qgEKgK6F/P PQD5Ca16AAiB3YMksL1hafZztgVmMtjTp+BOCNH6o/eD43ppwdkCON9IkfMKZfFlGkqV wlPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mail-followup-to:mime-version:content-disposition:user-agent; bh=3093sPFniKdvfBvTjD0OIzJq6EL6GR0Xt2s6E5hxDBw=; b=Eo2DokUUu16vDc1B+3Z53IGbopI/dB5EBhqhjyQA6tLd3CjoNq19byLFehAp1m10Ie CLyJ2DOTG3KYVblaifaKKAsVfAS/Qk53K878O2s8Kt3pAsN6Nq3TCR0KJ5SnK4hpVd7/ fmenr5XN2kZzMNovV3WvUZ4Ib79T9W450LByfjJwEmlwPNpFPEIEsxMKKrmSzfWUexZ8 NNGgiDMPEstWeYCkrBId1u8ofZ+zxtiugwzsfi2mYkX1sHECytNDiB1zeJO6aPUdibyP vB405lxD1LDV7lfLm2AEUXd0aNFtgjTzirEtGKb9aozRKeFouJUmUoxMEFvI1e8F3iPa rGFQ== X-Gm-Message-State: APjAAAUEgoJQNoPV5la6XZ8w+qzyOjwoDpfrUCDxYZiVrQoQyQIekmGS pZtlRUSlAXRUYwPALoHEqn5Y0j73 X-Google-Smtp-Source: APXvYqx3P/b4ZoQvpBl/IST+N6175EEnDx+kP35zoYii/dfutRzwt9N90UmgEeEYazda4vru/q9U0w== X-Received: by 2002:a7b:cf32:: with SMTP id m18mr583396wmg.27.1562012220343; Mon, 01 Jul 2019 13:17:00 -0700 (PDT) Received: from v2 (cpc92302-cmbg19-2-0-cust461.5-4.cable.virginm.net. [82.1.209.206]) by smtp.gmail.com with ESMTPSA id o11sm627034wmh.37.2019.07.01.13.16.58 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 01 Jul 2019 13:16:59 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 1 Jul 2019 21:16:57 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Call for 2019Q2 quarterly status reports Message-ID: <20190701201657.GA23686@v2> Mail-Followup-To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 8B77D8E31C X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=WdUdy5QY; spf=pass (mx1.freebsd.org: domain of etnapierala@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=etnapierala@gmail.com X-Spamd-Result: default: False [-7.67 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[trasz@freebsd.org,etnapierala@gmail.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[trasz@freebsd.org,etnapierala@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; IP_SCORE(-2.88)[ip: (-9.35), ipnet: 2a00:1450::/32(-2.63), asn: 15169(-2.35), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[0.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MID_RHS_NOT_FQDN(0.50)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 20:17:03 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is July 31, 2019, for work done since the last round of Quarterly Reports: April, 2019 =E2=80=93 June, 2019. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarterly@FreeBSD.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-s= ample.md The old XML generator and templates are no longer used. We look forward to seeing your 2019Q2 reports! Thanks, Edward (on behalf of quarterly@) --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGmBAEBCgCQFiEEbvjBe1hu6u1NeinjJCKD+Vwk/7oFAl0aajlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZF RjhDMTdCNTg2RUVBRUQ0RDdBMjlFMzI0MjI4M0Y5NUMyNEZGQkESHHRyYXN6QGZy ZWVic2Qub3JnAAoJECQig/lcJP+6fTEIAJxTthe2e7TP+SaKrQJNImOux9KWvOOB SCL55ZJYY2LRzkKxfdjxlRaU5trB03iQADdbLHZKMl5PUs88LtaY9A15/ZvoOv07 SpEoR8QcJfushBct1MaKP37NsFL7hn6AwfHOxLpH7l6THf49KkaBplmST4+tK0Qs euLOkJL2fgXoQ/KGnJMUOh+MBdb3mLTJSzuBWs31/99JzZq/9gJ5FcAR5qliksy9 GcFw+r2gKHfk/FcvG2SB5QNYbplLd4h8JUuZzAU0j4hcXCH4yhzI6Cu2NTphAYC+ QOojAj1LhQZ3KN8aNBJONNWyba7lzqWvkW4WnmoSvH1PwOEvVvzJ1X4= =4kOu -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-current@freebsd.org Wed Jul 3 12:07:50 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 021E815D227B for ; Wed, 3 Jul 2019 12:07:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7157E70D1A for ; Wed, 3 Jul 2019 12:07:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2FB4E15D227A; Wed, 3 Jul 2019 12:07:49 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A60515D2279 for ; Wed, 3 Jul 2019 12:07:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2882670D15 for ; Wed, 3 Jul 2019 12:07:46 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id x63C7dgc053851 for ; Wed, 3 Jul 2019 12:07:39 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id x63C7djn053850 for current@freebsd.org; Wed, 3 Jul 2019 05:07:39 -0700 (PDT) (envelope-from david) Date: Wed, 3 Jul 2019 05:07:39 -0700 From: David Wolfskill To: current@freebsd.org Subject: No keyboard or mouse for X11 after r349596 -> r349645 update Message-ID: <20190703120739.GN1328@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="begLTCnIYz0n3Vg2" Content-Disposition: inline User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 2882670D15 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 198.144.209.73 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-4.02 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.144.209.73]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[catwhisker.org]; MX_GOOD(-0.01)[mx.catwhisker.org]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; RCVD_IN_DNSWL_NONE(0.00)[73.209.144.198.list.dnswl.org : 127.0.10.0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:7961, ipnet:198.144.208.0/20, country:US]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-3.64)[ip: (-9.53), ipnet: 198.144.208.0/20(-4.91), asn: 7961(-3.72), country: US(-0.06)]; REPLYTO_EQ_TO_ADDR(5.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:07:50 -0000 --begLTCnIYz0n3Vg2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I saw no issues on my (headless) build machine with the update, but on my laptop (where I run xdm), the mouse was unresponsive, and I see these messages (in /var/log/messages): <28>1 2019-07-03T11:34:32.927353+00:00 g1-49.catwhisker.org console-kit-dae= mon 1142 - - WARNING: Error waiting for native console 1 activation: Inappr= opriate ioctl for device <28>1 2019-07-03T11:34:32.927400+00:00 g1-49.catwhisker.org console-kit-dae= mon 1142 - - WARNING: Error waiting for native console 9 activation: Inappr= opriate ioctl for device <37>1 2019-07-03T11:34:39.152108+00:00 g1-49.catwhisker.org login 1263 - - = ROOT LOGIN (root) ON ttyv1 <13>1 2019-07-03T11:34:45.329489+00:00 g1-49.catwhisker.org devd 808 - - ch= eck_clients: dropping disconnected client <13>1 2019-07-03T11:35:45.350116+00:00 g1-49.catwhisker.org syslogd - - - l= ast message repeated 1 times <28>1 2019-07-03T11:35:47.565077+00:00 g1-49.catwhisker.org console-kit-dae= mon 1142 - - WARNING: Error waiting for native console 1 activation: Inappr= opriate ioctl for device <28>1 2019-07-03T11:35:47.565157+00:00 g1-49.catwhisker.org console-kit-dae= mon 1142 - - WARNING: Error waiting for native console 2 activation: Inappr= opriate ioctl for device <28>1 2019-07-03T11:35:47.565201+00:00 g1-49.catwhisker.org console-kit-dae= mon 1142 - - WARNING: Error waiting for native console 9 activation: Inappr= opriate ioctl for device I note that: * Ports are built under stable/11. * I have the misc/compat11x port installed. * On the laptop in question (and my build machine), I update: * stable/11 * installed ports * stable/12 * head daily, in that sequence. * This has been working for a long time, but X11 isn't seeing the keyboard or mouse in head now. (They worked fine yesterday, running r349596.) Both respond on vtys: I copy/pasted a fair bit of this, and it's the laptop's keyboard I am using to type it. * The updates today were: * stable/11: r349575 -> r349648 * installed ports (r505669 -> r505743): * Upgrade of libuv-1.30.0 to libuv-1.30.1 * Upgrade of ffmpeg-4.1.3_13,1 to ffmpeg-4.1.3_14,1 * stable/12: r349572 -> r349644 * head: r349596 -> r349645 Is there, perhaps, a configuration knob I need to adjust? Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org No, Mr. Trump, I do NOT "have people on both sides of that". The five young men were shown to be factually innocent back in 2002. You are exacerbating hatred and advocating lynching. You should be ashamed. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --begLTCnIYz0n3Vg2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl0cmotfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pcl7ZQf+Pc2nVCF/rqUbxpQBryhXM5Xx2spk4dHNd9nRJw6nXuwhIslqy84OcJOK 71gvJQTGC8r9SL0LD27RzkdkKd9+LaPd92uB/KV7WJIWuNdQajpmIAfnTgbapgRx uJkHfQimmBCCDYmnKRKOPhRnRKfg0sS9u09Bjqfs5etFKOBVpIFtLJ0NH42atHGi 21aYi73qJQMCweUNIT+yngZF89BcP3uL251b93cLzFlMZzf4NmrIM3j4rsilDS1N jinkZ5MykYJRLntoKEFrA4s3Lk8pFwzLwG5KHAHrHVYTSzfja6zot3Bg99KOGxFG iLYxy3RjdjZE0wVxxL+Ddtd5Cbw73w== =qQi2 -----END PGP SIGNATURE----- --begLTCnIYz0n3Vg2-- From owner-freebsd-current@freebsd.org Wed Jul 3 12:16:32 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CC5415D2938 for ; Wed, 3 Jul 2019 12:16:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 32CEF71426 for ; Wed, 3 Jul 2019 12:16:31 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id E550115D2932; Wed, 3 Jul 2019 12:16:30 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3D1E15D2931 for ; Wed, 3 Jul 2019 12:16:30 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2538B71425 for ; Wed, 3 Jul 2019 12:16:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id x63CGSs6054056 for ; Wed, 3 Jul 2019 12:16:28 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id x63CGS2F054055 for current@freebsd.org; Wed, 3 Jul 2019 05:16:28 -0700 (PDT) (envelope-from david) Date: Wed, 3 Jul 2019 05:16:28 -0700 From: David Wolfskill To: current@freebsd.org Subject: Re: No keyboard or mouse for X11 after r349596 -> r349645 update Message-ID: <20190703121628.GO1328@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20190703120739.GN1328@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IScF4dT6yTbCq9Wi" Content-Disposition: inline In-Reply-To: <20190703120739.GN1328@albert.catwhisker.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 2538B71425 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.973,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:16:32 -0000 --IScF4dT6yTbCq9Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 03, 2019 at 05:07:39AM -0700, David Wolfskill wrote: > ....=20 OK; that was ... weird. I sent the above message (from a tmux session on a different machine), and the laptop dropped to the db> prompt; the backtrace appears to have involved deadlkres(), but when I tried typing "panic," I got a reboot (and no dump). (I did take a screenshot, if that's of interest.) On reboot, the keyboard & mouse appear to work as usual, running: FreeBSD g1-49.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #401 r349645= M/349648: Wed Jul 3 04:27:12 PDT 2019 root@g1-49.catwhisker.org:/commo= n/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 Color me "rather perplexed." :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org No, Mr. Trump, I do NOT "have people on both sides of that". The five young men were shown to be factually innocent back in 2002. You are exacerbating hatred and advocating lynching. You should be ashamed. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --IScF4dT6yTbCq9Wi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl0cnJxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcmSHAgAvcq7KSns542L6o9FVEBMaVOjIZ8hNv9eLdMw/34pJ8xJE3IRY3veOpg+ C7KzaTHAFE0fC7/29Nw0DbEt98B4llweXo7MycdEMHACdMvYQ6yPYIaAJPcVuk54 ISFT6gELd2QVTMymQNhTe6hoDvpjLilNBob9RzOXR2Kplcncw0wp5FxXDg7XfarS nNjH3JQgIV6+PzCvO0Xk6XQ2SB1JSxGJxHrJxy57M+b8n95ZtHNLpvPVJ0D11K9E phf8u+/P4Ikp5NBe0xLLUvUQFxOdhY5lbZNp3Rb5XNjvnrrzdfLNI2gAmL0aYnEg gl7umQkRK6llOL74mc+DaSgwM2dVpg== =dokV -----END PGP SIGNATURE----- --IScF4dT6yTbCq9Wi-- From owner-freebsd-current@freebsd.org Fri Jul 5 00:28:55 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 104E115E11C5 for ; Fri, 5 Jul 2019 00:28:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670089.outbound.protection.outlook.com [40.107.67.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B59176F34; Fri, 5 Jul 2019 00:28:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0287.CANPRD01.PROD.OUTLOOK.COM (10.165.219.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.16; Fri, 5 Jul 2019 00:28:51 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.019; Fri, 5 Jul 2019 00:28:51 +0000 From: Rick Macklem To: "freebsd-current@FreeBSD.org" CC: "kib@freebsd.org" , Alan Somers Subject: should a copy_file_range(2) syscall be interrupted via a signal Thread-Topic: should a copy_file_range(2) syscall be interrupted via a signal Thread-Index: AQHVMsfe501Pgm1HEESW4i3o9xExQA== Date: Fri, 5 Jul 2019 00:28:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b21f22d-0a02-4e70-1877-08d700dfc125 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0287; x-ms-traffictypediagnostic: YTXPR01MB0287: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(376002)(39850400004)(396003)(189003)(199004)(486006)(81166006)(6506007)(81156014)(256004)(54906003)(46003)(14444005)(33656002)(5640700003)(14454004)(478600001)(6916009)(8936002)(476003)(99286004)(305945005)(53936002)(68736007)(4326008)(71200400001)(8676002)(786003)(86362001)(71190400001)(186003)(2501003)(64756008)(316002)(73956011)(66446008)(66946007)(76116006)(66476007)(66556008)(9686003)(102836004)(6306002)(450100002)(55016002)(52536014)(4744005)(6436002)(2351001)(7696005)(5660300002)(2906002)(74316002)(25786009)(966005)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0287; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2azly+4NlI9ZJsYpkN+61Jw79sJy69oxL74UB0qQNVOrHQhJM3j9Hgy5fx1Hojtz5S8js9eR8ssMfcqPMnHuzyfH3AB1QzWJsbWN374FeY+bYCoBvyg7pzrTVas9tCTszfnS/v/qRXT20GJqIkAWb0TlQgZa7PNkkQSl7sgYVr6IO5EzCSBaE8+RDVaphfRZF2OgDKzcw1LDILA6DM7VsGFQCfWEGjRSwNVqWQ1DgsWO4wdBH1k8rl84F6lwd4UzqX62CxE6oTIjC5VU6GaSyhNtGJPVQrSlGMdEB8B2dV3aaTZjKdxJfwVKjLxneQ+ZyundWSQzylvG91Zz3aBWMH01u+IZC9BjqMu4LZmlSMwXS9UQCzVXBTvSw9o7lw5n6UpYrb3sp7apArvvzA0fO6ho5jcURH+O4X7jErz3Us8= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 4b21f22d-0a02-4e70-1877-08d700dfc125 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 00:28:51.3484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0287 X-Rspamd-Queue-Id: 3B59176F34 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.89 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.10 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.03)[ipnet: 40.64.0.0/10(-2.89), asn: 8075(-2.19), country: US(-0.06)]; MX_GOOD(-0.01)[mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.76)[-0.763,0]; RCVD_IN_DNSWL_NONE(0.00)[89.67.107.40.list.dnswl.org : 127.0.3.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 00:28:55 -0000 Hi, I have been working on a Linux compatible copy_file_range(2) syscall (the current code can be found at https://reviews.freebsd.org/D20584). One outstanding issue is how it should deal with signals. Right now, I have vn_start_write() without PCATCH, so that it won't be interrupted by a signal, but I notice that vn_write() {ie. write syscall } = does have PCATCH on vn_start_write() and so does vn_rdwr() when it is called without IO_NODELOCKED. I am thinking that copy_file_range(2) should do this also. However, if it returns an error, it is impossible for the caller to know ho= w much of the data range got copied. What do you think the copy_file_range(2) code should do? Thanks, rick ps: I've used FreeBSD-current@ this time, to see if I get more replies than= I did using FreeBSD-fs@. From owner-freebsd-current@freebsd.org Fri Jul 5 00:38:10 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EABA515E15D3 for ; Fri, 5 Jul 2019 00:38:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670042.outbound.protection.outlook.com [40.107.67.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F91077497; Fri, 5 Jul 2019 00:38:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 00:38:06 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.019; Fri, 5 Jul 2019 00:38:06 +0000 From: Rick Macklem To: "freebsd-current@FreeBSD.org" CC: Alan Somers , "kib@freebsd.org" Subject: test program for copy_file_range(2) Thread-Topic: test program for copy_file_range(2) Thread-Index: AQHVMskgzujQNZ0SzEiZ5jXklpLAxw== Date: Fri, 5 Jul 2019 00:38:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 914165b6-8749-47c2-da56-08d700e10c28 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:YTXPR01MB0285; x-ms-traffictypediagnostic: YTXPR01MB0285: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(136003)(376002)(396003)(189003)(199004)(6506007)(99936001)(55016002)(99286004)(53936002)(6436002)(54906003)(68736007)(7696005)(4744005)(5640700003)(2906002)(74482002)(33656002)(52536014)(71200400001)(9686003)(486006)(71190400001)(2501003)(478600001)(14454004)(76116006)(66946007)(2351001)(8936002)(25786009)(450100002)(4326008)(5660300002)(81156014)(8676002)(66476007)(786003)(476003)(46003)(64756008)(316002)(66556008)(81166006)(66616009)(66446008)(186003)(73956011)(86362001)(256004)(102836004)(74316002)(305945005)(6916009)(5024004); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0285; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /ASv31/glGg6npIgmYkXrRfvIFH4qDB6tRe+90dYoyRuHuNDFEE+vzuHTN6h0fsMj4teMv/YsHncZ9TfpE/bPQe8Pkpay9IjBaoltVPaiDMZ0M8eniuKpGnStqvz9eI3KQY34SBEpmpLJ2gsDuB2cDyBgRFlq0EN9kGtYLgWR+76XDtRL1NwrxbqP66QSKfP5PmCt+UTHsTdY/l0X7T0rmEFplbUtCRLeOjAPrKfkkLy0UTtT2Do/+E5hqA9Hm8PEBBm2PYeRIwARz7pj1iPBvjPew1JsLKjNhKUndKjEV/ydxE5NLTMOQXvGcRaOFQIrUyyWLydRMh7wN0xWBP51eNOgttzkpPfiCsM/98Yd0Lo2/1o43vC27YBP7N0YfRH7XA5uTo/8vI8ciaOX9Xof6OLUQsWP4JH/acOnIguvzU= Content-Type: multipart/mixed; boundary="_002_YTXPR01MB02854ED77B07C7434C2F442EDDF50YTXPR01MB0285CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 914165b6-8749-47c2-da56-08d700e10c28 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 00:38:06.7409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0285 X-Rspamd-Queue-Id: 7F91077497 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.42 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.02 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; CTYPE_MIXED_BOGUS(1.00)[]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-0.79)[-0.790,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DMARC_NA(0.00)[uoguelph.ca]; IP_SCORE(-1.03)[ipnet: 40.64.0.0/10(-2.89), asn: 8075(-2.19), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[42.67.107.40.list.dnswl.org : 127.0.3.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 00:38:10 -0000 --_002_YTXPR01MB02854ED77B07C7434C2F442EDDF50YTXPR01MB0285CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a little program for testing the copy_file_range(2) syscall I've bee= n working on. (The current version is attached, in case anyone is interested.= ) It take a few minutes to run on a slow system and uses about 6Gbytes of dis= k space for the file system the output file is on. (It creates 2 files to use= for testing. The first one is sparse and the second is copied from it, but grows as diff= erent byte ranges get copied, since "punching holes" is done via writes of 0 bytes.) My question is.. What needs to be done to include this in FreeBSD? I see some stuff under head/tests. I could probably figure out what the macros in those files are, but I can only see tests to see if arguments are valid and similar. As such, I'm not sure if this is the corre= ct place for a test like this? Thanks for any help with this, rick --_002_YTXPR01MB02854ED77B07C7434C2F442EDDF50YTXPR01MB0285CANP_ Content-Type: text/plain; name="testcfr.c" Content-Description: testcfr.c Content-Disposition: attachment; filename="testcfr.c"; size=4281; creation-date="Fri, 05 Jul 2019 00:38:02 GMT"; modification-date="Fri, 05 Jul 2019 00:38:02 GMT" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRib29sLmg+CiNpbmNsdWRlIDxzdGRsaWIu aD4KI2luY2x1ZGUgPHN0cmluZy5oPgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPGVycm5v Lmg+CiNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVk ZSA8c3lzL3N0YXQuaD4KI2luY2x1ZGUgPGVyci5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CgpzdGF0 aWMgY2hhciBqdW5rYnVmWzEyOCAqIDEwMjRdOwovKgogKiBXcml0ZSB4ZmVyIGJ5dGVzIGludG8g b3V0ZmQuCiAqLwpzdGF0aWMgdm9pZApqdW5rX3dyaXRlKGludCBvdXRmZCwgb2ZmX3QgeGZlcikK ewoJc2l6ZV90IGxlbjsKCXNzaXplX3Qgb3V0c2l6OwoKCWRvIHsKCQlpZiAoeGZlciA+IHNpemVv ZihqdW5rYnVmKSkKCQkJbGVuID0gc2l6ZW9mKGp1bmtidWYpOwoJCWVsc2UKCQkJbGVuID0geGZl cjsKCQlvdXRzaXogPSB3cml0ZShvdXRmZCwganVua2J1ZiwgbGVuKTsKCQlpZiAob3V0c2l6ICE9 IGxlbikKCQkJZXJyKDEsICJDYW4ndCB3cml0ZSBqdW5rIik7CgkJeGZlciAtPSBvdXRzaXo7Cgl9 IHdoaWxlICh4ZmVyID4gMCk7Cn0KCi8qIENvbXBhcmUgdGhlIHR3byBmaWxlcyBmb3Igc2FtZSBk YXRhLiAqLwpzdGF0aWMgdm9pZApjb21wX2ZpbGVzKGludCBpbmZkLCBpbnQgb3V0ZmQsIG9mZl90 IHNlZWtvZmYsIG9mZl90IHNlZWtvdXQsIG9mZl90IHhmZXIpCnsKCWNoYXIgYnVmWzEyOCAqIDEw MjRdLCBidWYyWzEyOCAqIDEwMjRdOwoJc3NpemVfdCBpbnNpeiwgb3V0c2l6OwoKCWlmIChzZWVr b2ZmID09IHNlZWtvdXQpIHsKCQlsc2VlayhpbmZkLCAwLCBTRUVLX1NFVCk7CgkJbHNlZWsob3V0 ZmQsIDAsIFNFRUtfU0VUKTsKCQl4ZmVyID0gMDsKCX0gZWxzZSB7CgkJbHNlZWsoaW5mZCwgc2Vl a29mZiwgU0VFS19TRVQpOwoJCWxzZWVrKG91dGZkLCBzZWVrb3V0LCBTRUVLX1NFVCk7Cgl9Cglk byB7CgkJaW5zaXogPSByZWFkKGluZmQsIGJ1Ziwgc2l6ZW9mKGJ1ZikpOwoJCWlmIChpbnNpeiA8 IDApCgkJCWVycigxLCAiQ2FuJ3QgcmVhZCBpbmZkIik7CgkJb3V0c2l6ID0gcmVhZChvdXRmZCwg YnVmMiwgc2l6ZW9mKGJ1ZjIpKTsKCQlpZiAob3V0c2l6IDwgMCkKCQkJZXJyKDEsICJDYW4ndCBy ZWFkIG91dGZkIik7CgkJaWYgKHhmZXIgPT0gMCkgewoJCQlpZiAoaW5zaXogPCBvdXRzaXopCgkJ CQllcnJ4KDEsICJQcmVtYXR1cmUgRU9GIG9uIGluZmQiKTsKCQkJaWYgKG91dHNpeiA8IGluc2l6 KQoJCQkJZXJyeCgxLCAiUHJlbWF0dXJlIEVPRiBvbiBvdXRmZCIpOwoJCX0gZWxzZSBpZiAoaW5z aXogPiBvdXRzaXopCgkJCWluc2l6ID0gb3V0c2l6OwoJCWlmIChpbnNpeiA+IDAgJiYgbWVtY21w KGJ1ZiwgYnVmMiwgaW5zaXopICE9IDApCgkJCWVycngoMSwgIkZpbGUgZGF0YSBub3Qgc2FtZSIp OwoJCWlmICh4ZmVyID4gMCkgewoJCQl4ZmVyIC09IGluc2l6OwoJCQlpZiAoeGZlciA9PSAwKQoJ CQkJaW5zaXogPSAwOwoJCX0KCX0gd2hpbGUgKGluc2l6ID4gMCk7Cn0KCi8qCiAqIENvcHkgYSBm aWxlIHJhbmdlIGZyb20gaW5mZCB0byBvdXRmZC4KICovCnN0YXRpYyB2b2lkCmNvcHlfcmFuZ2Uo aW50IGluZmQsIGludCBvdXRmZCwgb2ZmX3QgeGZlcikKewoJc2l6ZV90IGxlbjsKCXNzaXplX3Qg cmV0OwoKCXdoaWxlICh4ZmVyID4gMCkgewoJCWlmICh4ZmVyID4gU0laRV9UX01BWCkKCQkJbGVu ID0gU0laRV9UX01BWDsKCQllbHNlCgkJCWxlbiA9IHhmZXI7CgkJcmV0ID0gY29weV9maWxlX3Jh bmdlKGluZmQsIE5VTEwsIG91dGZkLCBOVUxMLCBsZW4sIDApOwoJCWlmIChyZXQgPD0gMCkKCQkJ ZXJyKDEsICJDb3B5IHJhbmdlIGZhaWxlZCEiKTsKCQl4ZmVyIC09IHJldDsKCX0KfQoKaW50Cm1h aW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKewoJaW50IGksIGluZmQsIGosIG91dGZkOwoJc3Ry dWN0IHN0YXQgc3QsIG91dHN0OwoJb2ZmX3Qgc2Vla29mZiwgc2Vla291dCwgeGZlcjsKCWJvb2wg Y2hlY2tfYWxsb2M7CgljaGFyIGNwOwoKCWlmIChhcmdjICE9IDMpCgkJZXJyeCgxLCAiVXNhZ2U6 IHRlc3RjZnIgPGluZmlsZT4gPG91dGZpbGU+Iik7CgkvKiBGaWxsIGluIGp1bmtfYnVmIHdpdGgg dGhlIGFscGhhYmV0IG92ZXIgYW5kIG92ZXIgYW5kIG92ZXIgYWdhaW4uICovCgljcCA9ICdhJzsK CWZvciAoaSA9IDA7IGkgPCBzaXplb2YoanVua2J1Zik7IGkrKykgewoJCWp1bmtidWZbaV0gPSBj cCsrOwoJCWlmIChjcCA+ICd6JykKCQkJY3AgPSAnYSc7Cgl9CglpbmZkID0gb3Blbihhcmd2WzFd LCBPX0NSRUFUIHwgT19SRFdSLCAwNjQ0KTsKCWlmIChpbmZkIDwgMCkKCQllcnIoMSwgImNhbid0 IG9wZW4gJXMiLCBhcmd2WzFdKTsKCW91dGZkID0gb3Blbihhcmd2WzJdLCBPX0NSRUFUIHwgT19S RFdSLCAwNjQ0KTsKCWlmIChvdXRmZCA8IDApCgkJZXJyKDEsICJjYW4ndCBjcmVhdGUgJXMiLCBh cmd2WzJdKTsKCglzZWVrb2ZmID0gMDsKCS8qCgkgKiBDcmVhdGUgdGhlIGlucHV0IGZpbGUgYXMg YSBzcGFyc2UgZmlsZSBhbmQgdGhlbiBjb3B5IGZpbGUgcmFuZ2VzCgkgKiBvZiBpdCB0byB0aGUg b3V0cHV0IGZpbGUgYW5kIGNvbXBhcmUgdGhlIHR3byBmaWxlcy4KCSAqLwoJZm9yIChpID0gMDsg aSA8IDI7IGkrKykgewoJCWlmIChpID4gMCkgewoJCQlzZWVrb2ZmID0gMTAyNCAqIDEwMjQgKiAx MDI0OwoJCQlzZWVrb2ZmICo9IDY7CgkJCWZ0cnVuY2F0ZShpbmZkLCAwKTsKCQkJZnRydW5jYXRl KG91dGZkLCAwKTsKCQl9CgkJbHNlZWsoaW5mZCwgc2Vla29mZiwgU0VFS19TRVQpOwoJCXdyaXRl KGluZmQsICJYWFhYIiwgNCk7CgkJbHNlZWsoaW5mZCwgMjU2ICogMTAyNCwgU0VFS19DVVIpOwoJ CXdyaXRlKGluZmQsICJZWVlZIiwgNCk7CgkJbHNlZWsoaW5mZCwgNTEyICogMTAyNCwgU0VFS19D VVIpOwoJCXdyaXRlKGluZmQsICJaWlpaIiwgNCk7CgoJCWxzZWVrKGluZmQsIDAsIFNFRUtfU0VU KTsKCQlsc2VlayhvdXRmZCwgMCwgU0VFS19TRVQpOwoJCWlmIChmc3RhdChpbmZkLCAmc3QpIDwg MCkKCQkJZXJyKDEsICJjYW4ndCBmc3RhdCAlcyIsIGFyZ3ZbMV0pOwoJCWNoZWNrX2FsbG9jID0g ZmFsc2U7CgkJaWYgKHN0LnN0X3NpemUgPCBTU0laRV9NQVgpCgkJCWNoZWNrX2FsbG9jID0gdHJ1 ZTsKCQlmb3IgKGogPSAwOyBqIDwgMTA7IGorKykgewoJCQlpZiAoaiA9PSAwKSB7CgkJCQlzZWVr b3V0ID0gc2Vla29mZiA9IDA7CgkJCQl4ZmVyID0gc3Quc3Rfc2l6ZTsKCQkJfSBlbHNlIHsKCQkJ CXNlZWtvZmYgPSByYW5kb20oKTsKCQkJCXNlZWtvZmYgKj0gNDsKCQkJCWlmIChzZWVrb2ZmIDw9 IDApCgkJCQkJc2Vla29mZiA9IDEyOCAqIDEwMjQ7CgkJCQlzZWVrb2ZmICU9IHN0LnN0X3NpemUg LyAyOwoJCQkJeGZlciA9IHJhbmRvbSgpOwoJCQkJeGZlciAqPSA0OwoJCQkJaWYgKHhmZXIgPD0g MCB8fCB4ZmVyID4gc3Quc3Rfc2l6ZSAtIHNlZWtvZmYpCgkJCQkJeGZlciA9IHN0LnN0X3NpemUg LSBzZWVrb2ZmOwoKCQkJCXNlZWtvdXQgPSBzZWVrb2ZmOwoJCQkJaWYgKGogPT0gOSkgewoJCQkJ CXNlZWtvdXQgPSBzZWVrb2ZmIC8gMjsKCQkJCQlsc2VlayhvdXRmZCwgc2Vla291dCwgU0VFS19T RVQpOwoJCQkJCWp1bmtfd3JpdGUob3V0ZmQsIHhmZXIpOwoJCQkJfSBlbHNlIGlmICgoaiAlIDIp ID09IDApIHsKCQkJCQlmdHJ1bmNhdGUob3V0ZmQsIHNlZWtvdXQpOwoJCQkJCXhmZXIgPSBzdC5z dF9zaXplIC0gc2Vla29mZjsKCQkJCX0gZWxzZSB7CgkJCQkJbHNlZWsob3V0ZmQsIHNlZWtvdXQs IFNFRUtfU0VUKTsKCQkJCQlqdW5rX3dyaXRlKG91dGZkLCB4ZmVyKTsKCQkJCX0KCQkJfQpwcmlu dGYoInNlZWtvZmY9JXFkIHNlZWtvdXQ9JXFkIHhmZXI9JXFkXG4iLCBzZWVrb2ZmLCBzZWVrb3V0 LCB4ZmVyKTsKCQkJbHNlZWsoaW5mZCwgc2Vla29mZiwgU0VFS19TRVQpOwoJCQlsc2VlayhvdXRm ZCwgc2Vla291dCwgU0VFS19TRVQpOwoJCQljb3B5X3JhbmdlKGluZmQsIG91dGZkLCB4ZmVyKTsK CgkJCS8qIENvbXBhcmUgaW5mZCB3aXRoIG91dGZkLiAqLwoJCQljb21wX2ZpbGVzKGluZmQsIG91 dGZkLCBzZWVrb2ZmLCBzZWVrb3V0LCB4ZmVyKTsKCQkJaWYgKGNoZWNrX2FsbG9jICYmIHNlZWtv ZmYgPT0gMCkgewoJCQkJaWYgKGZzdGF0KG91dGZkLCAmb3V0c3QpIDwgMCkKCQkJCQllcnIoMSwg ImNhbid0IGZzdGF0ICVzIiwgYXJndlsyXSk7CgkJCQlpZiAoc3Quc3RfYmxvY2tzICE9IG91dHN0 LnN0X2Jsb2NrcykKCQkJCQllcnJ4KDEsICJhbGxvY2F0aW9uIG5vdCBzYW1lIik7CgkJCX0KCQl9 Cgl9Cn0K --_002_YTXPR01MB02854ED77B07C7434C2F442EDDF50YTXPR01MB0285CANP_-- From owner-freebsd-current@freebsd.org Fri Jul 5 13:59:28 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECAF015CB73C for ; Fri, 5 Jul 2019 13:59:27 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3C2D70A0C; Fri, 5 Jul 2019 13:59:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 120282601E2; Fri, 5 Jul 2019 15:59:22 +0200 (CEST) Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal To: Rick Macklem , "freebsd-current@FreeBSD.org" Cc: "kib@freebsd.org" , Alan Somers References: From: Hans Petter Selasky Message-ID: <8c7707d7-f315-d613-705f-40b1619a7553@selasky.org> Date: Fri, 5 Jul 2019 15:58:45 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E3C2D70A0C X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.57 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; NEURAL_HAM_SHORT(-0.70)[-0.698,0]; IP_SCORE(-2.56)[ip: (-9.07), ipnet: 2a01:4f8::/29(-1.94), asn: 24940(-1.77), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 13:59:28 -0000 On 2019-07-05 02:28, Rick Macklem wrote: > I am thinking that copy_file_range(2) should do this also. > However, if it returns an error, it is impossible for the caller to know how much > of the data range got copied. How can you kill a program stuck on copy_file_range(2) w/o catching signals? --HPS From owner-freebsd-current@freebsd.org Fri Jul 5 14:31:35 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E0B615CC0F4 for ; Fri, 5 Jul 2019 14:31:35 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61AEA71B1F; Fri, 5 Jul 2019 14:31:34 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f45.google.com with SMTP id q26so6473947lfc.3; Fri, 05 Jul 2019 07:31:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2P131pVAMOD1RLf+jxYXBwWplYRqY63n77kgtRRigt8=; b=VOw+GPdISx2J+hKAOUQH/8FKC3HVBNSPRNNDoYpvDQ9L9y5Hq7KfoU8cB2Ahcog3H6 f7uc/Gz9VG1Eb5CALp+fd6vI9OOeOn8hL8tPZ0QmDOxQuAlRj3Gt1NpUumr2o6uHQM3C 0jAqZdRLxJwT2TN3ro+sMEl/QDXk0kfI4IrZY12+nuJ7wATJJ0pfR3GUI2QvzVxR4zdk F5ID3X/tvTJrGWgRtJd0RgWFXinnp79JP2nG+s+0EKWs3Gf1nzhQd+7hgYJE4T328ZEX 5um3Fp1DZCRnqplokCSB1Ug/t9u4HvhqTNev9XHwq59WM69NTJUmPgoaWbsB3olQnT1J hxTQ== X-Gm-Message-State: APjAAAU5SC1uAs7XjEknV9fvI4nFu9PWWLtjXt5caiqaMjuX+inwN2YU j28De/YzWBcfvHk7cp8191zASXFd2+ygTzwm8bw= X-Google-Smtp-Source: APXvYqzpM6jO44MUcJkuXNJy7MmXCSMHSKIdT1EEgDJ5T3cRDyTuJnWModlTB3RsukZJ8dfobzhh70jgHHLEpZcOTIQ= X-Received: by 2002:a19:7509:: with SMTP id y9mr2191279lfe.117.1562337086839; Fri, 05 Jul 2019 07:31:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 5 Jul 2019 08:31:15 -0600 Message-ID: Subject: Re: test program for copy_file_range(2) To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 61AEA71B1F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.81 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.50)[0.499,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[45.167.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.30)[ip: (-0.57), ipnet: 209.85.128.0/17(-3.46), asn: 15169(-2.40), country: US(-0.06)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 14:31:35 -0000 On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem wrote: > > I have a little program for testing the copy_file_range(2) syscall I've been > working on. (The current version is attached, in case anyone is interested.) > > It take a few minutes to run on a slow system and uses about 6Gbytes of disk > space for the file system the output file is on. (It creates 2 files to use for testing. > The first one is sparse and the second is copied from it, but grows as different byte > ranges get copied, since "punching holes" is done via writes of 0 bytes.) > > My question is.. > What needs to be done to include this in FreeBSD? > I see some stuff under head/tests. I could probably figure out > what the macros in those files are, but I can only see tests to see if > arguments are valid and similar. As such, I'm not sure if this is the correct > place for a test like this? > > Thanks for any help with this, rick head/tests is for complete automated tests, mostly in ATF format. Your program sounds more like the kind of helper program that might be more suitable for head/tools/regression. Those programs all require some operator interaction. If you can automate your program then we should add it to head/tests/sys. Does it really need 6GB to get decent test coverage? -Alan From owner-freebsd-current@freebsd.org Fri Jul 5 14:38:52 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6EF215CC2B5 for ; Fri, 5 Jul 2019 14:38:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA2A971F97; Fri, 5 Jul 2019 14:38:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd43.google.com with SMTP id g20so9997656ioc.12; Fri, 05 Jul 2019 07:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=sXEhGWBPd9eKKvov0dS+fsM3Za1nsfie/olhmeZuCd0=; b=Spqx/A+GqlqMz3RrBfK8dkEMcjFbzKAzH1FCqazgMn07GLmSoiS/mVobMWQ26NcRs8 aKMHo/qDjkI1QBQp39ZKPEIj7jU9vr7I3zMLmWdJCuRaTrEEJUIQUqLlch8IoHvq7aZZ uQg+xcEDTdY9gJDM54Vh38ZlVJIz802OfJetFDae9bODY8OFWqwy3CYM5QRUJflhHLWW pDU6CQmD98HxhISDCoQQ1IuJGiZNeBS1lVRALzqzOyZEG88sJfabwDAfoUpTsiTWbGuy RNu+rHO7RS4ZHxxgPnDdWZqVRoOZ+YOT9oMW2Nyv3ysKLAGdhQrKGD1d3SGClsGalKSH nZag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=sXEhGWBPd9eKKvov0dS+fsM3Za1nsfie/olhmeZuCd0=; b=LTdR+vq4+vrS7Tx8Rid1byq5Wi+CAZfhzdOneEJtFoTYNKsRzT84Qxn9QCujRDw+J2 agK2runuiZAssSg4wJIN0/Qy2yq0rBIcD53dkuypZDlF+P6w+XJLr3V2F7SPKQtq5Si7 LqBxG3sWSOwkapYH2TABxwW6JEa829oXyFxdHhlMaHAy11pOFie/NHrD8/6cclMBSXl6 HLox1zeM4oB3kbDr4PpDkQLuG6x7X0Qm0ZznMeW3N2Sl2J2GnyNjpwJ2Nkj/zL58zg4k jHJKAtIFRQH0H0bOBgDAZZpI0nJzk/mu6eJ86hON7/b25Uw/kWTfnRdkJ3nEenT2EMWP HvGQ== X-Gm-Message-State: APjAAAVSnJSh6UE2XH3xETt+kQbvWkKQIwaWaeZH2qmCTpyPKuhtfuBm Wy9wNEqymnmbrrRhrRqbXutPnXOV X-Google-Smtp-Source: APXvYqyHZoSqT0RoK0aSaf2QU6764FMwgjAGSghFW53Vr7MHlNYZTyGT9fu5Ov0ZqLeZoqjhTVbc+g== X-Received: by 2002:a6b:ed01:: with SMTP id n1mr4723366iog.255.1562337530989; Fri, 05 Jul 2019 07:38:50 -0700 (PDT) Received: from raichu (toroon0560w-lp140-05-70-29-85-38.dsl.bell.ca. [70.29.85.38]) by smtp.gmail.com with ESMTPSA id z26sm9830251ioi.85.2019.07.05.07.38.49 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 05 Jul 2019 07:38:50 -0700 (PDT) Sender: Mark Johnston Date: Fri, 5 Jul 2019 10:38:45 -0400 From: Mark Johnston To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" , Alan Somers Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Message-ID: <20190705143845.GA50901@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: AA2A971F97 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Spqx/A+G; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d43 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-3.06 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.54)[-0.542,0]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.81)[ip: (1.57), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.40), country: US(-0.06)]; MID_RHS_NOT_FQDN(0.50)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 14:38:52 -0000 On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: > Hi, > > I have been working on a Linux compatible copy_file_range(2) syscall > (the current code can be found at https://reviews.freebsd.org/D20584). > > One outstanding issue is how it should deal with signals. > Right now, I have vn_start_write() without PCATCH, so that it won't be > interrupted by a signal, but I notice that vn_write() {ie. write syscall } does > have PCATCH on vn_start_write() and so does vn_rdwr() when it is called > without IO_NODELOCKED. > > I am thinking that copy_file_range(2) should do this also. > However, if it returns an error, it is impossible for the caller to know how much > of the data range got copied. Couldn't copy_file_range() return the number of bytes copied in this case? (The Linux man page notes that short writes are possible.) I would expect to see the same error handling that we have in dofilewrite(), where certain errnos are squashed. > What do you think the copy_file_range(2) code should do? I'd find it surprising if copy_file_range() isn't interruptible. From owner-freebsd-current@freebsd.org Fri Jul 5 15:11:28 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F04915CD3EC for ; Fri, 5 Jul 2019 15:11:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670055.outbound.protection.outlook.com [40.107.67.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 497B57387B; Fri, 5 Jul 2019 15:11:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0287.CANPRD01.PROD.OUTLOOK.COM (10.165.219.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.16; Fri, 5 Jul 2019 15:11:25 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.022; Fri, 5 Jul 2019 15:11:25 +0000 From: Rick Macklem To: Alan Somers CC: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" Subject: Re: test program for copy_file_range(2) Thread-Topic: test program for copy_file_range(2) Thread-Index: AQHVMskgzujQNZ0SzEiZ5jXklpLAx6a8FweAgAAJc4g= Date: Fri, 5 Jul 2019 15:11:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 20945e27-5771-482c-e012-08d7015b0c5b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0287; x-ms-traffictypediagnostic: YTXPR01MB0287: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(136003)(366004)(396003)(199004)(189003)(68736007)(14454004)(52536014)(476003)(74482002)(99286004)(6506007)(486006)(256004)(14444005)(5024004)(2906002)(478600001)(316002)(5660300002)(7696005)(76176011)(786003)(186003)(53936002)(55016002)(86362001)(33656002)(4326008)(9686003)(71190400001)(71200400001)(74316002)(6916009)(66946007)(305945005)(6246003)(73956011)(81156014)(54906003)(81166006)(76116006)(8676002)(102836004)(46003)(8936002)(25786009)(450100002)(11346002)(6436002)(229853002)(64756008)(446003)(66476007)(66556008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0287; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: maLqU1wgJzSgYsskIghg810VUTJoyQREuMefv+iw/psSyMJdFKUnyHDEPugyJ4iaF+VEc1+h53j+Wj2BEKbm58gHF3JN2/FhqHslfsxFmU4cCllsfIcIqqNUTuILPy7LO8oIJI5AdBEQ3gMHIRi29uil3zkS5ZDhj8YxCUyJvZhyw/8KA45rzA9vnoJ9LiOgdhGQgXaxeKGcKAKPknEWPj18BvC93K3306HWGMIHS6R0MJI3/dEylPamdEIhX31EH77G4UI2oF9meUm2zy91WLLXoEFOvgm0r+kK8d4UVNIRP1yM7gUPYSvbE1MLNrUle0cnomA9OALvZPYteDTsL0sbVkRwepEJihvi+2AJ0IRmyU7S5xVzvn+B0iQJHKOj4eN/XREQXkGuICaigi0RJuINbHMSJFkeO5qa/2KTNzY= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 20945e27-5771-482c-e012-08d7015b0c5b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 15:11:25.5752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0287 X-Rspamd-Queue-Id: 497B57387B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.55 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.98 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.03)[ipnet: 40.64.0.0/10(-2.89), asn: 8075(-2.19), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.64)[-0.644,0]; RCVD_IN_DNSWL_NONE(0.00)[55.67.107.40.list.dnswl.org : 127.0.3.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:11:28 -0000 Alan Somers wrote: >On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem wrote: >> >> I have a little program for testing the copy_file_range(2) syscall I've = been >> working on. (The current version is attached, in case anyone is interest= ed.) >> >> It take a few minutes to run on a slow system and uses about 6Gbytes of = disk >> space for the file system the output file is on. (It creates 2 files to = use for testing. >> The first one is sparse and the second is copied from it, but grows as d= ifferent byte >> ranges get copied, since "punching holes" is done via writes of 0 bytes.= ) >> >> My question is.. >> What needs to be done to include this in FreeBSD? >> I see some stuff under head/tests. I could probably figure out >> what the macros in those files are, but I can only see tests to see if >> arguments are valid and similar. As such, I'm not sure if this is the co= rrect >> place for a test like this? >> >> Thanks for any help with this, rick > >head/tests is for complete automated tests, mostly in ATF format. >Your program sounds more like the kind of helper program that might be >more suitable for head/tools/regression. Those programs all require >some operator interaction. If you can automate your program then we >should add it to head/tests/sys. Does it really need 6GB to get >decent test coverage? Well, I wanted the input file to exceed 4Gb and to have a > 4Gb hole in it,= to catch 32bit bugs (I test on i386). This did catch some problems during testing. Then, the program copies (random) ranges of the file to a second file. If t= he random copy is done over the "big hole" for the case where it hasn't truncated the= output file (every second iteration), then it writes a "lot of 0s", growing the ou= tput file up to 6Gb of data. I could limit the "random" ranges to not copy the "big hole", but that woul= d avoid testing that case. rick From owner-freebsd-current@freebsd.org Fri Jul 5 15:28:00 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F7A515CDAB2 for ; Fri, 5 Jul 2019 15:28:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660070.outbound.protection.outlook.com [40.107.66.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09550745EC; Fri, 5 Jul 2019 15:27:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 15:27:56 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.022; Fri, 5 Jul 2019 15:27:56 +0000 From: Rick Macklem To: "freebsd-current@FreeBSD.org" CC: Jilles Tjoelker , Alan Somers , "kib@freebsd.org" Subject: Re: [Differential] D20584: add a linux compatible copy_file_range(2) syscall Thread-Topic: [Differential] D20584: add a linux compatible copy_file_range(2) syscall Thread-Index: ZWFiZDk2OGQzOWJhMWJjMTFmOGI0ODBmMTU5IF0fasTlG6fZzw== Date: Fri, 5 Jul 2019 15:27:56 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 38031f03-e1ed-4093-daff-08d7015d5ac5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0285; x-ms-traffictypediagnostic: YTXPR01MB0285: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(136003)(376002)(366004)(51444003)(199004)(189003)(478600001)(53936002)(4744005)(966005)(256004)(25786009)(9686003)(5660300002)(6246003)(53376002)(55016002)(14454004)(86362001)(74316002)(6306002)(6916009)(52536014)(76176011)(486006)(33656002)(2906002)(11346002)(446003)(476003)(7696005)(786003)(74482002)(2501003)(54906003)(71200400001)(2351001)(305945005)(102836004)(71190400001)(316002)(186003)(81156014)(8676002)(8936002)(66446008)(81166006)(66556008)(66946007)(450100002)(73956011)(46003)(66476007)(229853002)(76116006)(64756008)(68736007)(6506007)(99286004)(5640700003)(6436002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0285; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /of0b2qM0/ej53j/TQZ6suwtSxGOmnHJ+aPjGV4VoarYJfPmb1RwkDm5U3G7lTmzuKwtez7RVkogLJFIX0cU9GUzBT3ipXoS+6MgD6wFtdmgNx3kQy6ZivNsanEaPcRHwTT8wL5kb+MSpUPV3iTy8agFy63NqmFCX2SiM6j184XWdMVpmmtD7pS4UgqiiNoOTCyRLo2vJQdd1/Zo10C2R3+BNQla2jFZAdnq+yP2L7M0/DRupkGH2SoiARALOTYkvsgU9kVG8DpagIy+SQH1e4WVtFE5HYNPBolU8HEYXECqRHWbtLO9tWje/rDUstPZ4r2PTPHSaU5JglwBd4YxYPoJR93XW9IlAaXbr8Xj8vXKU406WMe7Kn4nz9I6mrH7XzJymYH1P/EXoB40p2kZMQw6OQTuroVUKHHCPgrUKik= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 38031f03-e1ed-4093-daff-08d7015d5ac5 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 15:27:56.1235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0285 X-Rspamd-Queue-Id: 09550745EC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.70 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.94 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.03)[ipnet: 40.64.0.0/10(-2.89), asn: 8075(-2.19), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.61)[-0.608,0]; RCVD_IN_DNSWL_NONE(0.00)[70.66.107.40.list.dnswl.org : 127.0.3.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:28:00 -0000 jilles wrote in copy_file_range.2:99 > The Linux man page (from http://man7.org/linux/man->pages/man2/copy_file_= range.2.html ) says that a non-zero flags argument will cause >the call to = return an [EINVAL] error. I think that is better than ignoring the argument= >completely since it allows adding flags more safely (since there will not= be existing >applications that pass in, for example, uninitialized data as= flags). The fun part is that the Linux folks are already discussing adding flags. I don't know if they are already in Linux-next (or whatever they call their= next release), but it sounded like they were headed that way. As such, I thought ignoring "flags" would be easier than returning EINVAL f= or code that works on Linux. However, I can see the counter argument, which is "returning EINVAL will indicate that the Linux flag isn't used on FreeBSD", so that developers wil= l become aware of that. What do others think w.r.t. which is the better approach? rick From owner-freebsd-current@freebsd.org Fri Jul 5 15:35:01 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AFA115CDE89 for ; Fri, 5 Jul 2019 15:35:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CD1974BE3; Fri, 5 Jul 2019 15:35:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f178.google.com with SMTP id x25so2913622ljh.2; Fri, 05 Jul 2019 08:35:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oepyiW1cdsyFQB3dNNlQhfmSQrdCaSK/WRHL/FFzHc8=; b=M46OFuh5xXsTYf0WoL6DdBmZ+lhmA9du35YbD6ssrmsJxv6rNphnejXtvlKnru/gxJ HhHe5/nguzIT30w4ODGk5ijdiOUZ0ErrpB8Qvh7P78rUnB+7le2HdUonnOC3PNxkZDgA 6Ty62I2UsAilnJ5GwmUXYr+dNa7h3To+onVjXeJTbmQ1BqUkIrslwQpW3sAJZEoHu9w1 9NvNNFDSIikpY4MGpwrsWueUCJrU1bmsho1cdf7pWu6Rw6W5haCMGNZWDbTEvElbxdck sRChRnA2Cyn5bBKi0AuGzWNZ/sCfrcg/G6wu/OndsIn6af+avzzjwU3zYXbR7YEOKfre OnkQ== X-Gm-Message-State: APjAAAUVBvXGktLk2s8PNkl/j3AY0svLtpDsH1a571GlYO3nSYcseYv4 hPuBmiyGSDtw5iFjoUgF2JsjzcgjtDJpGkRsIclknA== X-Google-Smtp-Source: APXvYqzjDhLdQ7z+sV92ZD1K0QTZbHDm3L6BimErQZJ3Os/MyNMFZSwNAXo5+JqVDI78nZNc2FvYNea588lqqzX++4M= X-Received: by 2002:a2e:2c07:: with SMTP id s7mr2407166ljs.44.1562336794169; Fri, 05 Jul 2019 07:26:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 5 Jul 2019 08:26:22 -0600 Message-ID: Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5CD1974BE3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.85 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.56)[-0.562,0]; RCVD_IN_DNSWL_NONE(0.00)[178.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.28)[ip: (-0.50), ipnet: 209.85.128.0/17(-3.46), asn: 15169(-2.40), country: US(-0.06)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:35:01 -0000 On Thu, Jul 4, 2019 at 6:29 PM Rick Macklem wrote: > > Hi, > > I have been working on a Linux compatible copy_file_range(2) syscall > (the current code can be found at https://reviews.freebsd.org/D20584). > > One outstanding issue is how it should deal with signals. > Right now, I have vn_start_write() without PCATCH, so that it won't be > interrupted by a signal, but I notice that vn_write() {ie. write syscall } does > have PCATCH on vn_start_write() and so does vn_rdwr() when it is called > without IO_NODELOCKED. > > I am thinking that copy_file_range(2) should do this also. > However, if it returns an error, it is impossible for the caller to know how much > of the data range got copied. > > What do you think the copy_file_range(2) code should do? > > Thanks, rick > ps: I've used FreeBSD-current@ this time, to see if I get more replies than I > did using FreeBSD-fs@. I though copy_file_range(2) is allowed to return short. Why can't it do that if it gets interrupted? From owner-freebsd-current@freebsd.org Fri Jul 5 15:43:52 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D762815CE217 for ; Fri, 5 Jul 2019 15:43:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC841752AE; Fri, 5 Jul 2019 15:43:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f171.google.com with SMTP id z28so760884ljn.4; Fri, 05 Jul 2019 08:43:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GWF1IdI4lbevLLEIVgF4lUs34/f6UIUmdabSZ2svUDM=; b=s76PN+YJYyhxDWU7kGiBdtacGcodVT7pM63IDTNqzVQ023eOoZjCO6PoCr92NbhlrC b6+ANvvWb3qTjyP9Yh43Y0ybtVQTHchQyiddF1VLRUSRxJqx2JOZLBrWpExYPMt24948 ZzFkNiirIUDg1FFZt8Z8/FCxhFTEEfXih3/pcdVQrYR3yzQmCyO8wo8LhYJnmEaUNnqz 6333SKpf1/qnVjc/I1wEMsR57ZCrxM2YONVe2Fqhkc6VqVipTuHnHK/Vv+UduZ400anl /QMYqKyYmrDgjysiH3pfEo8zJVo3elEzvHjpH9gxw62iBVz551bh8mD5fsRVg2kdJw8Z LGRA== X-Gm-Message-State: APjAAAUQTxoGOf4CczJ051X4JnhBNWJs9ZCWedrC3JVWxha4KhaTDF6w vehClhwyQwoa9OZktYGb1JgfjcWXvDs63nAQpLY= X-Google-Smtp-Source: APXvYqzZlV++w63QiqTxguuV0QArsxjZ8MW2hubv6OfLLBKPHJhaji82clRNH8T9oDCaNJqG7afiHX7FM46M0PuTRdU= X-Received: by 2002:a2e:1290:: with SMTP id 16mr2447785ljs.88.1562340963587; Fri, 05 Jul 2019 08:36:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 5 Jul 2019 09:35:51 -0600 Message-ID: Subject: Re: test program for copy_file_range(2) To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: CC841752AE X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.56 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.26)[-0.262,0]; RCVD_IN_DNSWL_NONE(0.00)[171.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.29)[ip: (-0.53), ipnet: 209.85.128.0/17(-3.46), asn: 15169(-2.40), country: US(-0.06)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:43:52 -0000 On Fri, Jul 5, 2019 at 9:11 AM Rick Macklem wrote: > > Alan Somers wrote: > >On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem wrote: > >> > >> I have a little program for testing the copy_file_range(2) syscall I've been > >> working on. (The current version is attached, in case anyone is interested.) > >> > >> It take a few minutes to run on a slow system and uses about 6Gbytes of disk > >> space for the file system the output file is on. (It creates 2 files to use for testing. > >> The first one is sparse and the second is copied from it, but grows as different byte > >> ranges get copied, since "punching holes" is done via writes of 0 bytes.) > >> > >> My question is.. > >> What needs to be done to include this in FreeBSD? > >> I see some stuff under head/tests. I could probably figure out > >> what the macros in those files are, but I can only see tests to see if > >> arguments are valid and similar. As such, I'm not sure if this is the correct > >> place for a test like this? > >> > >> Thanks for any help with this, rick > > > >head/tests is for complete automated tests, mostly in ATF format. > >Your program sounds more like the kind of helper program that might be > >more suitable for head/tools/regression. Those programs all require > >some operator interaction. If you can automate your program then we > >should add it to head/tests/sys. Does it really need 6GB to get > >decent test coverage? > Well, I wanted the input file to exceed 4Gb and to have a > 4Gb hole in it, to catch > 32bit bugs (I test on i386). This did catch some problems during testing. > > Then, the program copies (random) ranges of the file to a second file. If the random > copy is done over the "big hole" for the case where it hasn't truncated the output > file (every second iteration), then it writes a "lot of 0s", growing the output file > up to 6Gb of data. > > I could limit the "random" ranges to not copy the "big hole", but that would avoid > testing that case. > > rick random ranges are another problem. Automated tests shouldn't use random behavior, because then failures won't be reproducible. It's best to test a set of hand selected edge cases. If you're going to test random ranges too, then the program should use a user-selectable random seed (perhaps seeding from the timer if the user doesn't specify a seed, and printing the seed that was chosen). -Alan From owner-freebsd-current@freebsd.org Fri Jul 5 15:45:34 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0004915CE2EF for ; Fri, 5 Jul 2019 15:45:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21D7A753E7; Fri, 5 Jul 2019 15:45:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f193.google.com with SMTP id t28so9667088lje.9; Fri, 05 Jul 2019 08:45:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LzFEnssOpSzw3lCoWWS0aOGirLzbz/o3dUU8OCJSVMA=; b=LnjDoPCadklC15Adtvjr1HfBuf+vgN+olPiinviQXqqsXlUxcYh1ABpGDfgPuSB3EJ x6sLby55ejAjB68/YowYAW2xU1Z5vBuKPyEm/4DrZoq5K5F6mTxZqbmgGShaxfuaqHh2 2wyxiJedjfAkdX9lGx+rg6stLSjTedRN4vYzohL2rLiO9PHDuCI2E3qAs2Kg2O8sv7NE eceDucg7s6WxytwU+5usZfOLnlF52JCxP9Ysx8ydJ83BcSvopQST8U0dRQaL7DQWD4T5 yD5BWFNd0diqJXxw8lNkxzhWR2qs83zK4kzyljconS2AIg30SV2Bko8S4BR7luw4cBuE Ombw== X-Gm-Message-State: APjAAAWduK/5z0D/lnw4F+ozUWg9DoeH0efFY54cQsg3rNFE+Fb9wOwk C61tev/jGRuEt1/XLGlFjYYhkutqS0zSe7vVepI= X-Google-Smtp-Source: APXvYqzrnKBmE/isoXU5JVESEFMydW3YAeIe7NZYv7Bm6AV2IORXnBLoImHCSDlZonL+FdUsmCoFAabHRZaH3PuCk/c= X-Received: by 2002:a2e:9dc1:: with SMTP id x1mr2561966ljj.0.1562341080157; Fri, 05 Jul 2019 08:38:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 5 Jul 2019 09:37:48 -0600 Message-ID: Subject: Re: [Differential] D20584: add a linux compatible copy_file_range(2) syscall To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" , Jilles Tjoelker , "kib@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 21D7A753E7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.193 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.43 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.14)[-0.137,0]; RCVD_IN_DNSWL_NONE(0.00)[193.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.28)[ip: (-0.49), ipnet: 209.85.128.0/17(-3.46), asn: 15169(-2.40), country: US(-0.06)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[193.208.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:45:34 -0000 On Fri, Jul 5, 2019 at 9:28 AM Rick Macklem wrote: > > jilles wrote in copy_file_range.2:99 > > The Linux man page (from http://man7.org/linux/man->pages/man2/copy_fil= e_range.2.html ) says that a non-zero flags argument will cause >the call t= o return an [EINVAL] error. I think that is better than ignoring the argume= nt >completely since it allows adding flags more safely (since there will n= ot be existing >applications that pass in, for example, uninitialized data = as flags). > > The fun part is that the Linux folks are already discussing adding flags. > I don't know if they are already in Linux-next (or whatever they call the= ir next > release), but it sounded like they were headed that way. > > As such, I thought ignoring "flags" would be easier than returning EINVAL= for > code that works on Linux. > > However, I can see the counter argument, which is "returning EINVAL will > indicate that the Linux flag isn't used on FreeBSD", so that developers w= ill > become aware of that. > > What do others think w.r.t. which is the better approach? rick Better to return EINVAL. That way a program written for FreeBSD 14 which uses a FreeBSD 14-specific flag will fail when run on FreeBSD 13, which lacks that flag. -Alan From owner-freebsd-current@freebsd.org Fri Jul 5 15:51:52 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61D8715CE675 for ; Fri, 5 Jul 2019 15:51:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C72A175A56; Fri, 5 Jul 2019 15:51:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 15:51:49 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.022; Fri, 5 Jul 2019 15:51:49 +0000 From: Rick Macklem To: Mark Johnston CC: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" , Alan Somers Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Thread-Topic: should a copy_file_range(2) syscall be interrupted via a signal Thread-Index: AQHVMsfe501Pgm1HEESW4i3o9xExQKa8GSKAgAAN6Zk= Date: Fri, 5 Jul 2019 15:51:49 +0000 Message-ID: References: , <20190705143845.GA50901@raichu> In-Reply-To: <20190705143845.GA50901@raichu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f75d3bb-5ab6-4ca0-5df7-08d70160b0f5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0285; x-ms-traffictypediagnostic: YTXPR01MB0285: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(39860400002)(346002)(396003)(51914003)(199004)(189003)(54906003)(71200400001)(786003)(74482002)(186003)(316002)(71190400001)(305945005)(102836004)(33656002)(76176011)(486006)(476003)(7696005)(446003)(11346002)(2906002)(99286004)(6506007)(68736007)(6436002)(4326008)(66946007)(66556008)(81166006)(450100002)(8676002)(81156014)(8936002)(66446008)(64756008)(76116006)(73956011)(46003)(229853002)(66476007)(14444005)(25786009)(5660300002)(9686003)(256004)(53936002)(478600001)(966005)(6916009)(74316002)(6306002)(52536014)(14454004)(86362001)(6246003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0285; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: auzJx0V4qKHZkbzkemaFvJ/2XrEZCUIgFt0zRquwC7SAa5Nh7wjId2OgcR/lwzsNLh7w8IGUsfNtDpsr/grba5OkiVMVyPQyf1XNNE2IzND5MafBCO/ec7532JTWyVETOdoM9rbAHYawJOfAtOwS/oZCU8J8f3b8GP1Nm2/0A62GGyPe45zvr1QXB1M1BrZzuKjNweMupofitmWRIhybiPzFN7hYADTtuR+RFn7Zm6P/h9Wyf2pNoh4lhS4BfWSg97neyUlm83GkTrQ+67WUH7CWnHmBZRw989O5JEgFdxfnw+xvzh9QdFzV+QsCroDHAWqBmfHGj1XFBYk9Ol0Ik9g0sMmuphUOIn0/vEVnFHrdYailSSmz4rtsqnIsXwUugSYBGwKIdEwCJyNuelaWDtZhsIHn7A4Lj/nPhn1dsKg= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 6f75d3bb-5ab6-4ca0-5df7-08d70160b0f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 15:51:49.2722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0285 X-Rspamd-Queue-Id: C72A175A56 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::619 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.88 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-0.96)[ipnet: 2a01:111:f000::/36(-2.58), asn: 8075(-2.19), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.61)[-0.606,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:51:52 -0000 Mark Johnston wrote: >On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: >> Hi, >> >> I have been working on a Linux compatible copy_file_range(2) syscall >> (the current code can be found at https://reviews.freebsd.org/D20584). >> >> One outstanding issue is how it should deal with signals. >> Right now, I have vn_start_write() without PCATCH, so that it won't be >> interrupted by a signal, but I notice that vn_write() {ie. write syscall= } does >> have PCATCH on vn_start_write() and so does vn_rdwr() when it is called >> without IO_NODELOCKED. >> >> I am thinking that copy_file_range(2) should do this also. >> However, if it returns an error, it is impossible for the caller to know= how much >> of the data range got copied. > >Couldn't copy_file_range() return the number of bytes copied in this >case? (The Linux man page notes that short writes are possible.) I >would expect to see the same error handling that we have in >dofilewrite(), where certain errnos are squashed. I think this would be a good approach for local file systems, since I belie= ve that the only place that EINTR can be generated is the vn_start_write() call, si= nce vn_rdwr(IO_NODELOCKED) never returns it and the call completes before returning. As such, the EINTR happens at a "well known" place in the copy and a return= of the bytes copied should be fine. Now, for NFS, it gets a little weird... - For NFSv3, many use the "intr" mount option, which means that a VOP_WRITE= () can return EINTR and the caller doesn't know if the write succeeded on th= e NFS server or not. --> Returning "bytes copied" instead of an error for this case doesn't se= em appropriate to me, since there is no way to know if the last write h= appened? However, "intr" is not recommended for NFSv4 and NFSv4.2 is the only case w= here there is an RPC to do this on the server. Maybe nfs_copy_file_range() shouldn't "hide" EINTR, although the local file systems do so. I think sounds like a good approach. What do others think? >> What do you think the copy_file_range(2) code should do? > >I'd find it surprising if copy_file_range() isn't interruptible. I'll admit I haven't tested on Linux, so I don't know what happens there. The Linux man page doesn't mention EINTR, but I don't know what happens for a Linux "intr" NFS mount. I do have a Linux system for testing, but it = is the same system I have been using to test this syscall on FreeBSD. Maybe I need= to boot/play around with it. I do think returning "bytes copied" instead of EINTR is a good idea, where = practical. Thanks for the comments, rick From owner-freebsd-current@freebsd.org Fri Jul 5 15:59:45 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B26515CEBD4 for ; Fri, 5 Jul 2019 15:59:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670078.outbound.protection.outlook.com [40.107.67.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 539FC75E9D; Fri, 5 Jul 2019 15:59:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0286.CANPRD01.PROD.OUTLOOK.COM (10.165.219.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 15:59:41 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.022; Fri, 5 Jul 2019 15:59:41 +0000 From: Rick Macklem To: Hans Petter Selasky , "freebsd-current@FreeBSD.org" CC: "kib@freebsd.org" , Alan Somers Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Thread-Topic: should a copy_file_range(2) syscall be interrupted via a signal Thread-Index: AQHVMsfe501Pgm1HEESW4i3o9xExQKa8DfWAgAAgBaE= Date: Fri, 5 Jul 2019 15:59:41 +0000 Message-ID: References: , <8c7707d7-f315-d613-705f-40b1619a7553@selasky.org> In-Reply-To: <8c7707d7-f315-d613-705f-40b1619a7553@selasky.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f922b864-eb62-4eb6-5e23-08d70161ca93 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0286; x-ms-traffictypediagnostic: YTXPR01MB0286: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(346002)(376002)(199004)(189003)(25786009)(66476007)(64756008)(7696005)(76176011)(66946007)(66446008)(46003)(66556008)(76116006)(52536014)(86362001)(73956011)(478600001)(4326008)(54906003)(186003)(81156014)(2906002)(476003)(486006)(256004)(55016002)(102836004)(316002)(6246003)(786003)(68736007)(110136005)(81166006)(74482002)(8676002)(99286004)(305945005)(229853002)(8936002)(14444005)(446003)(2501003)(11346002)(53936002)(74316002)(6506007)(4744005)(33656002)(14454004)(5660300002)(9686003)(71200400001)(71190400001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0286; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: csqqY+mOhG04wfyL8QsG5RO9iXT2bDum1OnYgt4bKi3gFMBFjV9U3H56GBK8FdaNd7FB06Kyl9cQ4Shwh6dxc+zRe6UXym0D8a6usRS/2Wjl84bTDuutouDRVt03t85Y5ualILR0prplckVBDHjDg4RXWmXWLhIwiAox3FZkfRrD/SCxM9tU8Ah5sX39RxXJmEfwDjQrZANweP0zV6M577vRQ7pimTzAJkKLxd4YvWQP+FZI6PcJR+w2XuuYvm9V8wkoHA5ivz8UwR9OWVvYUHeVGyRfls3D2rqSoTF5spVIpvDcJo8LY4GoBXv+7H2DiIl4HL6s39ingBF8OJ817atABbgkF2Iu/IwO8bNbqsiYUdM+2zjq38mGmaXPFpatMlNIilk/w4WdQ1jIm5AR6ezc0JjWGFAeOU4cMiXxp0s= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: f922b864-eb62-4eb6-5e23-08d70161ca93 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 15:59:41.7945 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0286 X-Rspamd-Queue-Id: 539FC75E9D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.78 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.74 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.40)[-0.403,0]; RCVD_IN_DNSWL_NONE(0.00)[78.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.03)[ipnet: 40.64.0.0/10(-2.89), asn: 8075(-2.19), country: US(-0.06)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:59:45 -0000 Hans Petter Selasky wrote: >On 2019-07-05 02:28, Rick Macklem wrote: >> I am thinking that copy_file_range(2) should do this also. >> However, if it returns an error, it is impossible for the caller to know= how much >> of the data range got copied. > >How can you kill a program stuck on copy_file_range(2) w/o catching signal= s? Well, if "stuck" means sleeping somewhere inside the VOP_WRITE() call for the file system, I think it is "stuck" forever, just like write(2), isn't i= t? For NFS, the "intr" option might allow write(2) to return EINTR, but it oft= en takes a forced dismount (actually "umount -N") to get it "unstuck". However, I think for the case where the signal is detected outside of VOP_READ()/VOP_WRITE() in the copy loop, it does make sense to terminate it and I think the suggestion of returning "bytes copied" instead of EINTR = is a good one. rick From owner-freebsd-current@freebsd.org Fri Jul 5 15:59:51 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61DD315CEBE5 for ; Fri, 5 Jul 2019 15:59:51 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta02.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 485BE75EAA for ; Fri, 5 Jul 2019 15:59:49 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id jQIChvMTq3JQGjQIFhoJ0I; Fri, 05 Jul 2019 15:38:35 +0000 Received: from [192.168.1.100] (inspiron [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id x65FcWjE054585 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 5 Jul 2019 11:38:32 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host inspiron [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org To: FreeBSD Current From: Thomas Laus Subject: Problem with USB after r349133 Openpgp: preference=signencrypt Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= mQGiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthbQcVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPoh/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJcKgq6BQkhqyDOAAoJEOv/gtRiCDbP9xQAoL7B hCgFeI2K/0koKP3U8OB52nQyAJ0dd/QVJC7tV8gER4tse5GCUN5CHrkCDQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX64hmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAlwqCsMFCRhtvicACgkQ6/+C1GIINs/KCgCdGI1pg3HFhr7VEQeC63bhlMKH 0GAAn0mvTZY9OWKGMPoo0x/HdXkdgJHe Message-ID: <24b7304b-ce03-9be4-7b37-32b2d1d0f8ed@acm.org> Date: Fri, 5 Jul 2019 11:38:32 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFbHxyoZa7EqXfL5pkNbnSfUsItIVImJ/wq/6AMi81y/LX2dVI76hoT9+UsHwJzskIFuzyNlaeSMVB+4tld8TyxLfCoYI0L585R5kiDhr9REfSA5jzbz /Mr/JOnDTLWyWEGgaAjwNk316sulwKcSKLif3oaoUanak+qRU7WiTUpJ X-Rspamd-Queue-Id: 485BE75EAA X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=softfail (mx1.freebsd.org: 107.14.166.231 is neither permitted nor denied by domain of lausts@acm.org) smtp.mailfrom=lausts@acm.org X-Spamd-Result: default: False [-3.49 / 15.00]; HAS_REPLYTO(0.00)[lausts@acm.org]; HAS_XAW(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mail.mailroute.net,mail.mailroute.net]; NEURAL_HAM_SHORT(-0.63)[-0.628,0]; RECEIVED_SPAMHAUS_PBL(0.00)[189.112.29.65.zen.spamhaus.org : 127.0.0.10]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14065, ipnet:107.14.160.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[acm.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.76)[ipnet: 107.14.160.0/20(-2.07), asn: 14065(-1.65), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[231.166.14.107.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:59:51 -0000 I upgraded to CURRENT r349575 this week and my Dell Inspiron laptop stops processing the rc.conf with this message that repeats until I perform a hard power button reset, ctl-alt-del has no effect: Root mount waiting for USBUS7 USBUS6 .... USBUS0. I booted my kernel.old and everything is fine at r349133. I performed another CURRENT update today to r349765 and got the same result. Has there been any significant changes to the USB probing and mounting in the last few weeks. All of my desktops are not seeing this problem, it is only my Dell laptop. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Fri Jul 5 17:33:26 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D4A915D07CE for ; Fri, 5 Jul 2019 17:33:26 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from ecc05.stack.nl (ws0.zlo.nu [190.2.135.243]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.stack.nl", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05CC9813D4; Fri, 5 Jul 2019 17:33:24 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mail04.stack.nl (blade.stack.nl [51.15.111.152]) by ecc05.stack.nl (Postfix) with ESMTPS id D61F210029C; Fri, 5 Jul 2019 17:33:14 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail04.stack.nl (Postfix) with ESMTP id 9CB9610C6; Fri, 5 Jul 2019 17:33:14 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail04.stack.nl Received: from mail04.stack.nl ([127.0.0.1]) by localhost (mail04.stack.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDDsrCb6uQsp; Fri, 5 Jul 2019 17:30:55 +0000 (UTC) Received: from blade.stack.nl (blade.stack.nl [192.168.122.130]) by mail04.stack.nl (Postfix) with ESMTP id 064FC40F; Fri, 5 Jul 2019 17:30:55 +0000 (UTC) Received: by blade.stack.nl (Postfix, from userid 1677) id D956320FA7; Fri, 5 Jul 2019 19:30:54 +0200 (CEST) Date: Fri, 5 Jul 2019 19:30:54 +0200 From: Jilles Tjoelker To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" , Alan Somers Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Message-ID: <20190705173054.GA30404@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 05CC9813D4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of jilles@stack.nl designates 190.2.135.243 as permitted sender) smtp.mailfrom=jilles@stack.nl X-Spamd-Result: default: False [-2.56 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; NEURAL_HAM_MEDIUM(-0.81)[-0.814,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:190.2.135.243]; NEURAL_HAM_LONG(-0.99)[-0.989,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[stack.nl]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mail01.stack.nl]; NEURAL_HAM_SHORT(-0.44)[-0.444,0]; IP_SCORE(0.00)[asn: 49981(-0.01), country: NL(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49981, ipnet:190.2.128.0/20, country:NL]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 17:33:26 -0000 On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: > I have been working on a Linux compatible copy_file_range(2) syscall > (the current code can be found at https://reviews.freebsd.org/D20584). > One outstanding issue is how it should deal with signals. Right now, I > have vn_start_write() without PCATCH, so that it won't be interrupted > by a signal, but I notice that vn_write() {ie. write syscall } does > have PCATCH on vn_start_write() and so does vn_rdwr() when it is > called without IO_NODELOCKED. A regular write() is only interruptible when writing to a terminal, pseudo-terminal master, pipe, socket, or, under certain conditions, a file on an NFS intr mount. Therefore, applications may not have the code to resume interrupted writes to regular files gracefully. > I am thinking that copy_file_range(2) should do this also. > However, if it returns an error, it is impossible for the caller to > know how much of the data range got copied. A regular write() returns partial success if interrupted by a signal when it has already written something. Therefore, the application can resume the operation by adjusting pointers and counts. Something similar applies to "deterministic" errors like [EFBIG] where the first call will write as far as possible (if this is not nothing) successfully and the next attempt will return the error. > What do you think the copy_file_range(2) code should do? I'm not sure it should actually be done, but the need for adjusting pointers and counts could be avoided with a little extra kernel and libc code. The system call would receive an additional argument pointing to an off_t that indicates how many bytes previous calls have already written. A libc wrapper would initialize this to 0. With this, the system call can be restarted automatically after a signal. In any case, [EINTR] and the internal ERESTART must not be returned unless it is safe to repeat the call with the same (direct) arguments. -- Jilles Tjoelker From owner-freebsd-current@freebsd.org Fri Jul 5 17:48:58 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B77315D0D01 for ; Fri, 5 Jul 2019 17:48:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D6AD81D7F; Fri, 5 Jul 2019 17:48:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x65HmmQL076325 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Jul 2019 20:48:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x65HmmQL076325 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x65HmmMC076313; Fri, 5 Jul 2019 20:48:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Jul 2019 20:48:48 +0300 From: Konstantin Belousov To: Jilles Tjoelker Cc: Rick Macklem , "freebsd-current@FreeBSD.org" , Alan Somers Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Message-ID: <20190705174848.GG47193@kib.kiev.ua> References: <20190705173054.GA30404@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190705173054.GA30404@stack.nl> User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 17:48:58 -0000 On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote: > On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: > > I have been working on a Linux compatible copy_file_range(2) syscall > > (the current code can be found at https://reviews.freebsd.org/D20584). > > > One outstanding issue is how it should deal with signals. Right now, I > > have vn_start_write() without PCATCH, so that it won't be interrupted > > by a signal, but I notice that vn_write() {ie. write syscall } does > > have PCATCH on vn_start_write() and so does vn_rdwr() when it is > > called without IO_NODELOCKED. > > A regular write() is only interruptible when writing to a terminal, > pseudo-terminal master, pipe, socket, or, under certain conditions, a > file on an NFS intr mount. Therefore, applications may not have the code > to resume interrupted writes to regular files gracefully. > > > I am thinking that copy_file_range(2) should do this also. > > However, if it returns an error, it is impossible for the caller to > > know how much of the data range got copied. > > A regular write() returns partial success if interrupted by a signal > when it has already written something. Therefore, the application can > resume the operation by adjusting pointers and counts. > > Something similar applies to "deterministic" errors like [EFBIG] where > the first call will write as far as possible (if this is not nothing) > successfully and the next attempt will return the error. > > > What do you think the copy_file_range(2) code should do? > > I'm not sure it should actually be done, but the need for adjusting > pointers and counts could be avoided with a little extra kernel and libc > code. The system call would receive an additional argument pointing to > an off_t that indicates how many bytes previous calls have already > written. A libc wrapper would initialize this to 0. With this, the > system call can be restarted automatically after a signal. > > In any case, [EINTR] and the internal ERESTART must not be returned > unless it is safe to repeat the call with the same (direct) arguments. BTW, if the syscall is made interruptible, it should be made cancellable ? I think that PCATCH commonly used for vn_start_write(9) is not the best decision. It is safe in the sense explained by Jilles, since its interruption only happens at the very beginning of the syscall, but it contradict to the tradition of write(2) to the local fs being not interruptible. I suggest to not make the syscall interruptible by default, and perhaps only allow it with a flag. Then you would need to explain that the syscall is only interruptible between VOPs, it is up to fs to decide if the VOP_READ/VOP_WRITE is interruptible (e.g. devfs and nfs). From owner-freebsd-current@freebsd.org Fri Jul 5 20:59:25 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35F2015D46B0 for ; Fri, 5 Jul 2019 20:59:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670082.outbound.protection.outlook.com [40.107.67.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C058989659; Fri, 5 Jul 2019 20:59:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0286.CANPRD01.PROD.OUTLOOK.COM (10.165.219.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 20:59:23 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.022; Fri, 5 Jul 2019 20:59:23 +0000 From: Rick Macklem To: Konstantin Belousov , Jilles Tjoelker CC: "freebsd-current@FreeBSD.org" , Alan Somers Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Thread-Topic: should a copy_file_range(2) syscall be interrupted via a signal Thread-Index: AQHVMsfe501Pgm1HEESW4i3o9xExQKa8STsAgAAFAQCAADEg0g== Date: Fri, 5 Jul 2019 20:59:23 +0000 Message-ID: References: <20190705173054.GA30404@stack.nl>,<20190705174848.GG47193@kib.kiev.ua> In-Reply-To: <20190705174848.GG47193@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 92cb7d7b-716c-4e53-66ae-08d7018ba866 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0286; x-ms-traffictypediagnostic: YTXPR01MB0286: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39860400002)(366004)(136003)(51444003)(199004)(189003)(66476007)(7696005)(64756008)(76176011)(66946007)(46003)(66446008)(66556008)(76116006)(86362001)(25786009)(52536014)(91956017)(478600001)(4326008)(54906003)(186003)(81156014)(2906002)(476003)(486006)(966005)(256004)(55016002)(102836004)(786003)(316002)(6246003)(68736007)(110136005)(81166006)(8676002)(99286004)(305945005)(229853002)(8936002)(14444005)(446003)(11346002)(53936002)(74316002)(6506007)(33656002)(6306002)(71200400001)(14454004)(5660300002)(9686003)(6436002)(73956011)(71190400001)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0286; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sN3jl6UnvK4yi33jhUKypLCBdogRTshv/BOX7e14g57UWCcSyR7oOBmv7ObPHzm+/wfIpVaZ/zit2EXEAGT3GE1DNpS3k8XwZdehqDVL3FKAuTsG2ArZgMBCpkV/pckubPKs1byuCyK2VZ4+D2GTfBWnK0E8wjsBhuA4YoxKwVMz69SIgExUWbeXc2TMCSRfeyHH7crog7GrreFn0wsGwkr8hfoUGIhWRZy0AgSUM19fYm9ZGM1qxOsCoLmA7v/1Li8YfUja41a/0AoICDS1VWE4j1ZnKrMqxzzaqHFdKLYJVtu1tAD9bYAmVvOVyhA++dDJtgUTgowI3QGsEV9WV5LJX+CXNVCTPl94xYJIs4MY+4hMuWZYX6u8TApmcyR1g6jqIHvJCPUpr0001uzcW1gfW6Xv0NOZuUX9tj8g4KY= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 92cb7d7b-716c-4e53-66ae-08d7018ba866 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 20:59:23.2668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0286 X-Rspamd-Queue-Id: C058989659 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.943,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 20:59:25 -0000 Konstantin Belousov wrote: >On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote: >> On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: >> > I have been working on a Linux compatible copy_file_range(2) syscall >> > (the current code can be found at https://reviews.freebsd.org/D20584). >> >> > One outstanding issue is how it should deal with signals. Right now, I >> > have vn_start_write() without PCATCH, so that it won't be interrupted >> > by a signal, but I notice that vn_write() {ie. write syscall } does >> > have PCATCH on vn_start_write() and so does vn_rdwr() when it is >> > called without IO_NODELOCKED. >> >> A regular write() is only interruptible when writing to a terminal, >> pseudo-terminal master, pipe, socket, or, under certain conditions, a >> file on an NFS intr mount. Therefore, applications may not have the code >> to resume interrupted writes to regular files gracefully. Yes, agreed. Since this syscall only works on VREG vnodes, the only weird c= ases are NFS (and maybe fuse). I'll let asomers@ address the fuse situation. >> >> > I am thinking that copy_file_range(2) should do this also. >> > However, if it returns an error, it is impossible for the caller to >> > know how much of the data range got copied. >> >> A regular write() returns partial success if interrupted by a signal >> when it has already written something. Therefore, the application can >> resume the operation by adjusting pointers and counts. >> >> Something similar applies to "deterministic" errors like [EFBIG] where >> the first call will write as far as possible (if this is not nothing) >> successfully and the next attempt will return the error. >> >> > What do you think the copy_file_range(2) code should do? >> >> I'm not sure it should actually be done, but the need for adjusting >> pointers and counts could be avoided with a little extra kernel and libc >> code. The system call would receive an additional argument pointing to >> an off_t that indicates how many bytes previous calls have already >> written. A libc wrapper would initialize this to 0. With this, the >> system call can be restarted automatically after a signal. >> >> In any case, [EINTR] and the internal ERESTART must not be returned >> unless it is safe to repeat the call with the same (direct) arguments. Well, since the copy_file_range(2) syscall is allowed to return fewer bytes= copied than requested and this doesn't mean EOF, it seems that doing that would achieve the result of allowing an application to call it again. (Basically, it must be used in a loop until the bytes of the range have bee= n copied, since returning fewer bytes copied than requested is a normal outcome.) >BTW, if the syscall is made interruptible, it should be made cancellable ? Not sure what you mean by "cancellable"? If you mean "terminated by a signa= l where there has been no change to the output file, then that could only eas= ily be done by returning EINTR before any data has been copied. If you mean something else, then I'd need to know what that is? >I think that PCATCH commonly used for vn_start_write(9) is not the best >decision. It is safe in the sense explained by Jilles, since its interrup= tion >only happens at the very beginning of the syscall, but it contradict to th= e >tradition of write(2) to the local fs being not interruptible. > >I suggest to not make the syscall interruptible by default, and perhaps >only allow it with a flag. Then you would need to explain that the >syscall is only interruptible between VOPs, it is up to fs to decide if >the VOP_READ/VOP_WRITE is interruptible (e.g. devfs and nfs). This is how it is coded now. The one thing I have noticed is that a copy_file_range() can take a long time (about 2min for 2Gbytes on the old h= ardware I test on). This seems like a long delay for C when you do that to an= application copying a large file. ("cp" and "dd" also take 2min for 2Gbytes, so it isn'= t a bug in copy_file_range(2). It just introduces a long delay in response to C.) rick From owner-freebsd-current@freebsd.org Fri Jul 5 21:13:19 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D504F15D4B91 for ; Fri, 5 Jul 2019 21:13:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14F0E8A013; Fri, 5 Jul 2019 21:13:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x65LD9bv012542 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jul 2019 00:13:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x65LD9bv012542 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x65LD9QW012541; Sat, 6 Jul 2019 00:13:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Jul 2019 00:13:09 +0300 From: Konstantin Belousov To: Rick Macklem Cc: Jilles Tjoelker , "freebsd-current@FreeBSD.org" , Alan Somers Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Message-ID: <20190705211309.GI47193@kib.kiev.ua> References: <20190705173054.GA30404@stack.nl> <20190705174848.GG47193@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 21:13:19 -0000 On Fri, Jul 05, 2019 at 08:59:23PM +0000, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote: > >> On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: > >> > I have been working on a Linux compatible copy_file_range(2) syscall > >> > (the current code can be found at https://reviews.freebsd.org/D20584). > >> > >> > One outstanding issue is how it should deal with signals. Right now, I > >> > have vn_start_write() without PCATCH, so that it won't be interrupted > >> > by a signal, but I notice that vn_write() {ie. write syscall } does > >> > have PCATCH on vn_start_write() and so does vn_rdwr() when it is > >> > called without IO_NODELOCKED. > >> > >> A regular write() is only interruptible when writing to a terminal, > >> pseudo-terminal master, pipe, socket, or, under certain conditions, a > >> file on an NFS intr mount. Therefore, applications may not have the code > >> to resume interrupted writes to regular files gracefully. > Yes, agreed. Since this syscall only works on VREG vnodes, the only weird cases > are NFS (and maybe fuse). I'll let asomers@ address the fuse situation. > > >> > >> > I am thinking that copy_file_range(2) should do this also. > >> > However, if it returns an error, it is impossible for the caller to > >> > know how much of the data range got copied. > >> > >> A regular write() returns partial success if interrupted by a signal > >> when it has already written something. Therefore, the application can > >> resume the operation by adjusting pointers and counts. > >> > >> Something similar applies to "deterministic" errors like [EFBIG] where > >> the first call will write as far as possible (if this is not nothing) > >> successfully and the next attempt will return the error. > >> > >> > What do you think the copy_file_range(2) code should do? > >> > >> I'm not sure it should actually be done, but the need for adjusting > >> pointers and counts could be avoided with a little extra kernel and libc > >> code. The system call would receive an additional argument pointing to > >> an off_t that indicates how many bytes previous calls have already > >> written. A libc wrapper would initialize this to 0. With this, the > >> system call can be restarted automatically after a signal. > >> > >> In any case, [EINTR] and the internal ERESTART must not be returned > >> unless it is safe to repeat the call with the same (direct) arguments. > Well, since the copy_file_range(2) syscall is allowed to return fewer bytes copied > than requested and this doesn't mean EOF, it seems that doing that would > achieve the result of allowing an application to call it again. > (Basically, it must be used in a loop until the bytes of the range have been copied, > since returning fewer bytes copied than requested is a normal outcome.) > > >BTW, if the syscall is made interruptible, it should be made cancellable ? > Not sure what you mean by "cancellable"? If you mean "terminated by a signal > where there has been no change to the output file, then that could only easily be > done by returning EINTR before any data has been copied. > If you mean something else, then I'd need to know what that is? See pthread_setcancelstate(3) for start, but the POSIX 1003.1-2017 2.9.5 Thread Cancellation is the definitive spec, including the quite readable overview. > > >I think that PCATCH commonly used for vn_start_write(9) is not the best > >decision. It is safe in the sense explained by Jilles, since its interruption > >only happens at the very beginning of the syscall, but it contradict to the > >tradition of write(2) to the local fs being not interruptible. > > > >I suggest to not make the syscall interruptible by default, and perhaps > >only allow it with a flag. Then you would need to explain that the > >syscall is only interruptible between VOPs, it is up to fs to decide if > >the VOP_READ/VOP_WRITE is interruptible (e.g. devfs and nfs). > This is how it is coded now. The one thing I have noticed is that a > copy_file_range() can take a long time (about 2min for 2Gbytes on the old hardware > I test on). This seems like a long delay for C when you do that to an application > copying a large file. ("cp" and "dd" also take 2min for 2Gbytes, so it isn't a bug > in copy_file_range(2). It just introduces a long delay in response to C.) That long delay is inconvenience but not something that we should spent too much time trying to fix. We cause the same delay if program does a write(2) of several GB, or when very large process like firefox dumps core. From owner-freebsd-current@freebsd.org Fri Jul 5 21:37:26 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3CF015D536C for ; Fri, 5 Jul 2019 21:37:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660048.outbound.protection.outlook.com [40.107.66.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 983BE8B079; Fri, 5 Jul 2019 21:37:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM (10.165.219.7) by YTXPR01MB0288.CANPRD01.PROD.OUTLOOK.COM (10.165.219.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Fri, 5 Jul 2019 21:37:22 +0000 Received: from YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf]) by YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM ([fe80::9cc8:c3b7:19c2:7baf%4]) with mapi id 15.20.2032.022; Fri, 5 Jul 2019 21:37:22 +0000 From: Rick Macklem To: Alan Somers CC: "freebsd-current@FreeBSD.org" , "kib@freebsd.org" Subject: Re: test program for copy_file_range(2) Thread-Topic: test program for copy_file_range(2) Thread-Index: AQHVMskgzujQNZ0SzEiZ5jXklpLAx6a8FweAgAAJc4iAAAiagIAAYYWb Date: Fri, 5 Jul 2019 21:37:22 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c3219ff-f19c-4d54-fc1c-08d70190f70c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTXPR01MB0288; x-ms-traffictypediagnostic: YTXPR01MB0288: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(346002)(39860400002)(376002)(189003)(199004)(68736007)(52536014)(91956017)(66946007)(76116006)(74316002)(33656002)(305945005)(66476007)(64756008)(11346002)(446003)(66446008)(478600001)(2906002)(66556008)(486006)(5660300002)(25786009)(450100002)(476003)(86362001)(73956011)(229853002)(46003)(53936002)(81156014)(14454004)(9686003)(6246003)(6436002)(256004)(186003)(76176011)(74482002)(5024004)(102836004)(316002)(54906003)(4326008)(8936002)(99286004)(55016002)(71190400001)(14444005)(71200400001)(8676002)(6916009)(6506007)(81166006)(786003)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0288; H:YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /TA4ZjxCv//ZSNL4+814sBsTOYsxETa/4JSLYpNmhvGS1sqqoCIeU60PfvOMuyBwzZeTsEtFXmh/4oR3kLzSZ8i6LTfK7cX0Pml0ihVvJMofmCddAafw6VGmDklTWifw+AhFhvw3PdL6I/Z88MY8DC3AkHlnPK3JnN48/dSE1IV8mmu4Vdx4r7zBH/rmAEAOTs2Xn6q8ju5vrz6ocViDtbxWBCyXyxn9xU8pka9YoUe4gm69sW7m4Si0M1UBCsuaKmSv1Y8bQJmLHxfH4w/h1UYCxpoXwimV1q3Ifoy9UY1pyH3kkcx8YjvXmmXhqFBrUOXQE9YUz+S16I8WjY2+P5jUEbu4RWEK36X+IOfvmaV7f+XZwHN1vcSfYNZErGcwyzCvkvznuPatMDBEfkHYdJYuT2OoaxELGUFO+eXBYnM= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 4c3219ff-f19c-4d54-fc1c-08d70190f70c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 21:37:22.6575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0288 X-Rspamd-Queue-Id: 983BE8B079 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.48 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.84 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.03)[ipnet: 40.64.0.0/10(-2.89), asn: 8075(-2.19), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx2.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.50)[-0.504,0]; RCVD_IN_DNSWL_NONE(0.00)[48.66.107.40.list.dnswl.org : 127.0.3.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 21:37:26 -0000 Alan Somers wrote: >On Fri, Jul 5, 2019 at 9:11 AM Rick Macklem wrote: >> >> Alan Somers wrote: >> >On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem wrot= e: >> >> >> >> I have a little program for testing the copy_file_range(2) syscall I'= ve been >> >> working on. (The current version is attached, in case anyone is inter= ested.) >> >> >> >> It take a few minutes to run on a slow system and uses about 6Gbytes = of disk >> >> space for the file system the output file is on. (It creates 2 files = to use for testing. >> >> The first one is sparse and the second is copied from it, but grows a= s different byte >> >> ranges get copied, since "punching holes" is done via writes of 0 byt= es.) >> >> >> >> My question is.. >> >> What needs to be done to include this in FreeBSD? >> >> I see some stuff under head/tests. I could probably figure out >> >> what the macros in those files are, but I can only see tests to see i= f >> >> arguments are valid and similar. As such, I'm not sure if this is the= correct >> >> place for a test like this? >> >> >> >> Thanks for any help with this, rick >> > >> >head/tests is for complete automated tests, mostly in ATF format. >> >Your program sounds more like the kind of helper program that might be >> >more suitable for head/tools/regression. Those programs all require >> >some operator interaction. If you can automate your program then we >> >should add it to head/tests/sys. Does it really need 6GB to get >> >decent test coverage? >> Well, I wanted the input file to exceed 4Gb and to have a > 4Gb hole in = it, to catch >> 32bit bugs (I test on i386). This did catch some problems during testing= . >> >> Then, the program copies (random) ranges of the file to a second file. I= f the random >> copy is done over the "big hole" for the case where it hasn't truncated = the output >> file (every second iteration), then it writes a "lot of 0s", growing the= output file >> up to 6Gb of data. >> >> I could limit the "random" ranges to not copy the "big hole", but that w= ould avoid >> testing that case. >> >> rick > >random ranges are another problem. Automated tests shouldn't use >random behavior, because then failures won't be reproducible. It's >best to test a set of hand selected edge cases. If you're going to >test random ranges too, then the program should use a user-selectable >random seed (perhaps seeding from the timer if the user doesn't >specify a seed, and printing the seed that was chosen). Good points. Now, I'm about as far from an expert on testing as they come, = but the problem in this case is that I have already written the code to handle = the edge cases I recognized. (Ideally the guy who writes the test program isn't= the guy who wrote the code, but...) By doing the "random" stuff, I am hoping to catch cases that I hadn't antic= ipated. (I put the "random" in quotes, since I use random(3) without seeding it, so= I actually get the same reproducible results.) I crank the # of cycles up so that it runs for hours/days/weeks. I do agree I should add some specific edge cases (which I have already chec= ked) to the test program. rick From owner-freebsd-current@freebsd.org Fri Jul 5 22:06:24 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB33615D611E for ; Fri, 5 Jul 2019 22:06:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B2FA8C17B for ; Fri, 5 Jul 2019 22:06:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 70D682604A5; Sat, 6 Jul 2019 00:06:16 +0200 (CEST) Subject: Re: Problem with USB after r349133 To: lausts@acm.org, FreeBSD Current References: <24b7304b-ce03-9be4-7b37-32b2d1d0f8ed@acm.org> From: Hans Petter Selasky Message-ID: <9dd97691-8a5a-03d2-98a1-4ad952298f64@selasky.org> Date: Sat, 6 Jul 2019 00:05:40 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <24b7304b-ce03-9be4-7b37-32b2d1d0f8ed@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6B2FA8C17B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-6.42 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.93)[-0.925,0]; IP_SCORE(-3.18)[ip: (-9.39), ipnet: 88.99.0.0/16(-4.74), asn: 24940(-1.78), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 22:06:25 -0000 On 2019-07-05 17:38, Thomas Laus wrote: > I upgraded to CURRENT r349575 this week and my Dell Inspiron laptop > stops processing the rc.conf with this message that repeats until I > perform a hard power button reset, ctl-alt-del has no effect: > > Root mount waiting for USBUS7 USBUS6 .... USBUS0. > > I booted my kernel.old and everything is fine at r349133. I performed > another CURRENT update today to r349765 and got the same result. Has > there been any significant changes to the USB probing and mounting in > the last few weeks. All of my desktops are not seeing this problem, it > is only my Dell laptop. > There has been very few USB changes, except for ACPI USB support in: https://svnweb.freebsd.org/changeset/base/349161 https://svnweb.freebsd.org/changeset/base/349251 --HPS From owner-freebsd-current@freebsd.org Sat Jul 6 13:02:31 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDCAD15EBC50 for ; Sat, 6 Jul 2019 13:02:31 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta01.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A45AE8AD67 for ; Sat, 6 Jul 2019 13:02:30 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id jkKghgDFoE13vjkKihLRxJ; Sat, 06 Jul 2019 13:02:29 +0000 Received: from [192.168.1.100] (inspiron [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id x66D2PZd082740 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 6 Jul 2019 09:02:25 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host inspiron [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org Subject: Re: Problem with USB after r349133 To: Hans Petter Selasky , FreeBSD Current References: <24b7304b-ce03-9be4-7b37-32b2d1d0f8ed@acm.org> <9dd97691-8a5a-03d2-98a1-4ad952298f64@selasky.org> From: Thomas Laus Openpgp: preference=signencrypt Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= mQGiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthbQcVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPoh/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJcKgq6BQkhqyDOAAoJEOv/gtRiCDbP9xQAoL7B hCgFeI2K/0koKP3U8OB52nQyAJ0dd/QVJC7tV8gER4tse5GCUN5CHrkCDQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX64hmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAlwqCsMFCRhtvicACgkQ6/+C1GIINs/KCgCdGI1pg3HFhr7VEQeC63bhlMKH 0GAAn0mvTZY9OWKGMPoo0x/HdXkdgJHe Message-ID: <89942f11-7868-bfc4-5d12-521b2f2028a9@acm.org> Date: Sat, 6 Jul 2019 09:02:25 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <9dd97691-8a5a-03d2-98a1-4ad952298f64@selasky.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGRVYB+ucVnSuiCZAXZBulpXGs3XDfPbGwsKN8nbjXty9zZ8/a4nsT+XEm4TvHWsNNxOgG+bPs5Q0svL0RGkeQxwVIzR9/wI8EsOwBlUC2g4XkEikKeM VrCDmhJEma30kuU1OhGl1+dnIpcxY97UrmJe0B1G85WxGOu8znyrw7q3AW/o8UsB89YKihpI1Xym7A== X-Rspamd-Queue-Id: A45AE8AD67 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=softfail (mx1.freebsd.org: 107.14.166.230 is neither permitted nor denied by domain of lausts@acm.org) smtp.mailfrom=lausts@acm.org X-Spamd-Result: default: False [-3.72 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[lausts@acm.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[acm.org]; R_SPF_SOFTFAIL(0.00)[~all]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mail.mailroute.net]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[230.166.14.107.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.84)[-0.839,0]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[189.112.29.65.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14065, ipnet:107.14.160.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.77)[ipnet: 107.14.160.0/20(-2.10), asn: 14065(-1.68), country: US(-0.06)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 13:02:32 -0000 On 2019-07-05 18:05, Hans Petter Selasky wrote: > > There has been very few USB changes, except for ACPI USB support in: > > https://svnweb.freebsd.org/changeset/base/349161 > https://svnweb.freebsd.org/changeset/base/349251 > It looks like I will need to build a few kernels to see what changes made between r349133 and r349575 affected the USB Bus probes on my laptop. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Sat Jul 6 14:17:09 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E38F15ECFF3 for ; Sat, 6 Jul 2019 14:17:09 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FF928D55C for ; Sat, 6 Jul 2019 14:17:08 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id n9so12595785wru.0 for ; Sat, 06 Jul 2019 07:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=cgAAjOUfaJ6SrsBrQfsXafWgqICLtaeKI08BTpBihqc=; b=S3oO1HnG+pxWz7ahlISPX78myhJK/y68f10NyMksAtzLQvfKX3SzxO2gQEDtuBBE1+ YHjsVA7pV//bWHKfxfMXCgW+qtxKlu8pAxUzdEQqTW/DyW+Wso3IstEPvIPIIjo18BOJ DI0WT4FKl4yrLyHQBYyOOGj9Mtls/7cPqB7NbP4htpUbYh6DMzINMfF/QQZKOGUGa+xL 4VNKYaDmdsFwFG1it5MsiLhI//bGbC/BlFxsuVRis0RHQfnVwFK0k9PjA9Fujy47qXvw Jp6EGm+az5yTLeSlGOO4/KyySX+AIIerCfI8nVeprG9SWJvbCckBv/pneRhsUvTdFmQ9 QDgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cgAAjOUfaJ6SrsBrQfsXafWgqICLtaeKI08BTpBihqc=; b=gs955OtUMdVYSxlQHXT0UAUvfUf2AyAVVZyO4BmsuNOZPuLS/qkqK+XfaTVrxppnFa +YZoyjl7N8tHlzVlQV7NX5rJ+fvrf94WU8T0NhpZJ6lkUr3PPO61LLevdBZmFyTQUhKo TResRbTK/w0hlZuRH3L26wl9ikP8yi6eVvpuNTFmzJy6yM+qFpVr2xce3TuMImIWV4vU Ku4a8TuM3CNn9+qdtZjpGUJckkzpjGqLIZpqkneTd5KsZdtZvPMJg5KJhuixNQv0/HHE BR2gC7Ks9D4ygqWfc5WvScZ6/un5jKrOfsTRnIqFtviYYyx74+pTEwzapi7v9KQ/ZiMc TS0w== X-Gm-Message-State: APjAAAWLNUdc1RrzXGl3WD6OOouEPoFP4HnXXzvW63Gq8yc5+4BzUkli CzRplEA1S8AEm9F5GTrP261GbQ2JqpQ= X-Google-Smtp-Source: APXvYqyrOrvgSZUl7BcAPd0tvSaSe26hf6VporrrehbnNar8vVpI30178yJC6WUHXM2KMsMeh93csA== X-Received: by 2002:adf:8061:: with SMTP id 88mr8417688wrk.127.1562422625504; Sat, 06 Jul 2019 07:17:05 -0700 (PDT) Received: from [192.168.1.7] (79-66-151-94.dynamic.dsl.as9105.com. [79.66.151.94]) by smtp.gmail.com with ESMTPSA id f1sm8387733wml.28.2019.07.06.07.17.03 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jul 2019 07:17:04 -0700 (PDT) Subject: Re: Problem with USB after r349133 To: FreeBSD CURRENT References: <24b7304b-ce03-9be4-7b37-32b2d1d0f8ed@acm.org> From: Graham Perrin Message-ID: Date: Sat, 6 Jul 2019 15:17:03 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <24b7304b-ce03-9be4-7b37-32b2d1d0f8ed@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 1FF928D55C X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=S3oO1HnG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::429 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-6.68 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.76)[-0.757,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.91)[ip: (-9.34), ipnet: 2a00:1450::/32(-2.77), asn: 15169(-2.40), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[9.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 14:17:09 -0000 On 05/07/2019 16:38, Thomas Laus wrote: > Root mount waiting for USBUS7 USBUS6 .... USBUS0. I had the almost same (different bus numbers), just once, after updating -CURRENT from r349099 to r349762. The subsequent boot of r349762 was free from the symptom. HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech trackball connected to USB ports at the side of the dock. At one of the USB ports at the rear of the dock was a rechargeable motorised device, which I disconnected after the (one) USB issue. From owner-freebsd-current@freebsd.org Sat Jul 6 18:32:09 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D4CC15CF387 for ; Sat, 6 Jul 2019 18:32:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 00ADA711F5 for ; Sat, 6 Jul 2019 18:32:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x66IN1wY045200 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 6 Jul 2019 11:23:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x66IN15i045199 for freebsd-current@freebsd.org; Sat, 6 Jul 2019 11:23:01 -0700 (PDT) (envelope-from sgk) Date: Sat, 6 Jul 2019 11:23:01 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Someone broke USB Message-ID: <20190706182301.GA45149@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 00ADA711F5 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.16 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.39)[-0.390,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.19)[0.191,0]; MX_GOOD(-0.01)[troutmask.apl.washington.edu]; DMARC_NA(0.00)[washington.edu]; NEURAL_SPAM_MEDIUM(0.47)[0.473,0]; R_SPF_NA(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[ip: (0.07), ipnet: 128.95.0.0/16(0.07), asn: 73(-0.13), country: US(-0.06)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 18:32:09 -0000 Updated a month old FreeBSD-current to top of tree. Upon rebooting, the usb no longer functions. No usb mouse. No usb external hard drive. Unplugging and then re-plugging in external drive does not cause the drive to spin up. Logged in as root.` % usbconfig list No device match or lack of permissions % usbsonfig show_ifdrv No device match or lack of permissions % usbsonfig dump_all_desc No device match or lack of permissions % usbsonfig reset No device match or lack of permissions /usr/src/UPDATING does not show any recent entries for usb. So, how does one get usb working, again? -- Steve From owner-freebsd-current@freebsd.org Sat Jul 6 18:34:21 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC60515CF490 for ; Sat, 6 Jul 2019 18:34:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B70371498 for ; Sat, 6 Jul 2019 18:34:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4DB87260285; Sat, 6 Jul 2019 20:34:18 +0200 (CEST) Subject: Re: Someone broke USB To: sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org References: <20190706182301.GA45149@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> Date: Sat, 6 Jul 2019 20:33:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190706182301.GA45149@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8B70371498 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.36 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mail.turbocat.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.49)[-0.487,0]; IP_SCORE(-2.56)[ip: (-9.08), ipnet: 2a01:4f8::/29(-1.93), asn: 24940(-1.78), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 18:34:21 -0000 On 2019-07-06 20:23, Steve Kargl wrote: > So, how does one get usb working, again? > > -- Steve Can you show dmesg? --HPS From owner-freebsd-current@freebsd.org Sat Jul 6 18:45:50 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 374C315CF8F9 for ; Sat, 6 Jul 2019 18:45:50 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta01.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD7CC71CD9 for ; Sat, 6 Jul 2019 18:45:48 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id jpgohosdhE13vjpgqhNmMq; Sat, 06 Jul 2019 18:45:41 +0000 Received: from [192.168.1.100] (inspiron [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id x66IjbYF000951 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 6 Jul 2019 14:45:38 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host inspiron [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org Subject: Re: Problem with USB after r349133 To: freebsd-current@freebsd.org References: <24b7304b-ce03-9be4-7b37-32b2d1d0f8ed@acm.org> From: Thomas Laus Openpgp: preference=signencrypt Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= mQGiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthbQcVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPoh/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJcKgq6BQkhqyDOAAoJEOv/gtRiCDbP9xQAoL7B hCgFeI2K/0koKP3U8OB52nQyAJ0dd/QVJC7tV8gER4tse5GCUN5CHrkCDQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX64hmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAlwqCsMFCRhtvicACgkQ6/+C1GIINs/KCgCdGI1pg3HFhr7VEQeC63bhlMKH 0GAAn0mvTZY9OWKGMPoo0x/HdXkdgJHe Message-ID: <4910b8f9-7f83-1b6d-885f-81920c024827@acm.org> Date: Sat, 6 Jul 2019 14:45:37 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfA56rucBYws9gAhS+z7M0b2e7LoSZQhi8vY7yhDhDrKnal5XhabKCWotuAugHGz5Ua7HdLFNFyLLzScIeyG07T6SATdEjg2eDUXz8idkjhDkWAB9CJvu x3JTFDCR0YLMgD3AxhlqcvIZhI6W/slbal+6qWIKNdIYdEfclhvzf7Rc X-Rspamd-Queue-Id: BD7CC71CD9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=softfail (mx1.freebsd.org: 107.14.166.230 is neither permitted nor denied by domain of lausts@acm.org) smtp.mailfrom=lausts@acm.org X-Spamd-Result: default: False [-3.41 / 15.00]; HAS_REPLYTO(0.00)[lausts@acm.org]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[mail.mailroute.net,mail.mailroute.net]; NEURAL_HAM_SHORT(-0.52)[-0.523,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.78)[ipnet: 107.14.160.0/20(-2.14), asn: 14065(-1.71), country: US(-0.06)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14065, ipnet:107.14.160.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[189.112.29.65.zen.spamhaus.org : 127.0.0.10]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[acm.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[230.166.14.107.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 18:45:50 -0000 On 2019-07-06 10:17, Graham Perrin wrote: > > I had the almost same (different bus numbers), just once, after updating > -CURRENT from r349099 to r349762. > > The subsequent boot of r349762 was free from the symptom. > > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech > trackball connected to USB ports at the side of the dock. > > At one of the USB ports at the rear of the dock was a rechargeable > motorised device, which I disconnected after the (one) USB issue. > I just built and installed r349161 and observed the same problem with the rc.conf probe for USBUS7 ... USBUS0. I will build r349160 and make a report. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Sat Jul 6 19:12:03 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FECF15D00BA for ; Sat, 6 Jul 2019 19:12:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C16C72B4A for ; Sat, 6 Jul 2019 19:12:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x66JBxFM045436 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jul 2019 12:12:00 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x66JBxHp045435; Sat, 6 Jul 2019 12:11:59 -0700 (PDT) (envelope-from sgk) Date: Sat, 6 Jul 2019 12:11:59 -0700 From: Steve Kargl To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: Someone broke USB Message-ID: <20190706191159.GA45408@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190706182301.GA45149@troutmask.apl.washington.edu> <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 3C16C72B4A X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-0.03 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.15)[-0.147,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.74)[-0.737,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.03)[-0.028,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[ip: (0.07), ipnet: 128.95.0.0/16(0.07), asn: 73(-0.13), country: US(-0.06)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 19:12:03 -0000 On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: > On 2019-07-06 20:23, Steve Kargl wrote: > > So, how does one get usb working, again? > > > > -- Steve > > Can you show dmesg? > This is dmesg.boot for the kernel with the non-functioning USB stack. I'll need to reboot with the older kernel to get the dmesg.boot for a kernel with a functioning stack. Do you need that as well? ---<>--- Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT r349777 MOBILE i386 FreeBSD clang version 8.0.1 (branches/release_80 363030) (based on LLVM 8.0.1) VT(vga): resolution 640x480 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3654860800 (3485 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) random: unblocking device. ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard Launching APs: 1 Timecounter "TSC" frequency 1995047160 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xf2bd70, 0) error 19 [ath_hal] loaded [ath_dfs] loaded [ath_rate] loaded [ar9300] loaded [ar5212] loaded [ar5416] loaded [ar5211] loaded [ar5210] loaded [ath] loaded nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 cpu0: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Ignoring 3 range above 4GB (0x120000000-0x317ffffff) pci0: on pcib0 vgapci0: port 0xeff8-0xefff mem 0xfea00000-0xfeafffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory vgapci0: Boot video device vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 on pci0 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 usbus1 on uhci1 usbus1: 12Mbps Full Speed USB v1.0 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 usbus2: 480Mbps High Speed USB v2.0 hdac0: mem 0xfe9fc000-0xfe9fffff irq 21 at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pcib1: [GIANT-LOCKED] pcib2: at device 28.1 on pci0 pcib2: [GIANT-LOCKED] pci1: on pcib2 wpi0: mem 0xfe8ff000-0xfe8fffff irq 17 at device 0.0 on pci1 pcib3: at device 28.5 on pci0 pcib3: [GIANT-LOCKED] pci2: on pcib3 bge0: mem 0xfe7f0000-0xfe7fffff irq 17 at device 0.0 on pci2 bge0: CHIP ID 0x0000a002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:1d:09:ba:cc:0d uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 usbus3 on uhci2 usbus3: 12Mbps Full Speed USB v1.0 uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 usbus4 on uhci3 usbus4: 12Mbps Full Speed USB v1.0 uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 usbus5 on uhci4 usbus5: 12Mbps Full Speed USB v1.0 ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 usbus6: EHCI version 1.0 usbus6 on ehci1 usbus6: 480Mbps High Speed USB v2.0 pcib4: at device 30.0 on pci0 pci3: on pcib4 cbb0: at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pci3: at device 1.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eff mem 0xfe9fb800-0xfe9fbfff irq 17 at device 31.2 on pci0 ahci0: AHCI v1.10 with 3 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich2: at channel 2 on ahci0 ahciem0: on ahci0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff pnpid ORM0000 on isa0 ppc0: parallel port not found. est0: on cpu0 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 13,10 and 12,11 on hdaa0 ugen5.1: at usbus5 ugen3.1: at usbus3 ugen1.1: at usbus1 ugen6.1: at usbus6 ugen4.1: at usbus4 ugen2.1: at usbus2 ugen0.1: at usbus0 uhub0 on usbus5 uhub0: on usbus5 uhub1 on usbus3 uhub1: on usbus3 uhub2 on usbus1 uhub2: on usbus1 uhub3 on usbus6 uhub3: on usbus6 uhub5 on usbus2 uhub5: on usbus2 uhub4 on usbus4 uhub4: on usbus4 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ACS-4 ATA SATA 3.x device ada0: Serial Number 1B0607771A0800257271 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors) ses0: ada0 in 'Slot 00', SATA Slot: scbus1 target 0 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: 680MB (348277 2048 byte sectors) Trying to mount root from ufs:/dev/ada0s1a [rw]... uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered wlan0: Ethernet address: 00:1c:bf:90:ab:44 lo0: link state changed to UP wlan0: link state changed to UP -- Steve From owner-freebsd-current@freebsd.org Sat Jul 6 19:41:29 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCFD915D0ADA for ; Sat, 6 Jul 2019 19:41:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8052A7421A for ; Sat, 6 Jul 2019 19:41:27 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x66JfPvN045546 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jul 2019 12:41:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x66JfOuf045545; Sat, 6 Jul 2019 12:41:24 -0700 (PDT) (envelope-from sgk) Date: Sat, 6 Jul 2019 12:41:24 -0700 From: Steve Kargl To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: Someone broke USB Message-ID: <20190706194124.GA45536@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190706182301.GA45149@troutmask.apl.washington.edu> <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 8052A7421A X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-0.05 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.15)[-0.150,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.75)[-0.753,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.03)[-0.027,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[ip: (0.07), ipnet: 128.95.0.0/16(0.07), asn: 73(-0.13), country: US(-0.06)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 19:41:29 -0000 On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: > On 2019-07-06 20:23, Steve Kargl wrote: > > So, how does one get usb working, again? > > > > -- Steve > > Can you show dmesg? > It looks like the enumeration of busses and devices has changed. grepping for uhub and usbus of the working and broken dmesg.boot gives % grep uhub dmesg.boot.working uhub0: on usbus6 uhub1: on usbus4 uhub2: on usbus3 uhub3: on usbus1 uhub4: on usbus5 uhub5: on usbus2 uhub6: on usbus0 uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub5: 4 ports with 4 removable, self powered uhub0: 6 ports with 6 removable, self powered umass0 on uhub0 ukbd0 on uhub1 ums0 on uhub1 uhid0 on uhub1 % grep uhub dmesg.boot.broken uhub0 on usbus5 uhub0: on usbus5 uhub1 on usbus3 uhub1: on usbus3 uhub2 on usbus1 uhub2: on usbus1 uhub3 on usbus6 uhub3: on usbus6 uhub5 on usbus2 uhub5: on usbus2 uhub4 on usbus4 uhub4: on usbus4 uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered **** % grep usbus dmesg.boot.working usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1 on uhci1 usbus1: 12Mbps Full Speed USB v1.0 usbus2: EHCI version 1.0 usbus2 on ehci0 usbus2: 480Mbps High Speed USB v2.0 usbus3 on uhci2 usbus3: 12Mbps Full Speed USB v1.0 usbus4 on uhci3 usbus4: 12Mbps Full Speed USB v1.0 usbus5 on uhci4 usbus5: 12Mbps Full Speed USB v1.0 usbus6: EHCI version 1.0 usbus6 on ehci1 usbus6: 480Mbps High Speed USB v2.0 ugen6.1: at usbus6 uhub0: on usbus6 ugen4.1: at usbus4 uhub1: on usbus4 ugen3.1: at usbus3 uhub2: on usbus3 ugen1.1: at usbus1 uhub3: on usbus1 ugen5.1: at usbus5 uhub4: on usbus5 ugen2.1: at usbus2 uhub5: on usbus2 ugen0.1: at usbus0 uhub6: on usbus0 ugen6.2: at usbus6 umass0: on usbus6 ugen4.2: at usbus4 ukbd0: on usbus4 ums0: on usbus4 uhid0: on usbus4 % grep usbus dmesg.boot.broken usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1 on uhci1 usbus1: 12Mbps Full Speed USB v1.0 usbus2: EHCI version 1.0 usbus2 on ehci0 usbus2: 480Mbps High Speed USB v2.0 usbus3 on uhci2 usbus3: 12Mbps Full Speed USB v1.0 usbus4 on uhci3 usbus4: 12Mbps Full Speed USB v1.0 usbus5 on uhci4 usbus5: 12Mbps Full Speed USB v1.0 usbus6: EHCI version 1.0 usbus6 on ehci1 usbus6: 480Mbps High Speed USB v2.0 ugen5.1: at usbus5 ugen3.1: at usbus3 ugen1.1: at usbus1 ugen6.1: at usbus6 ugen4.1: at usbus4 ugen2.1: at usbus2 ugen0.1: at usbus0 uhub0 on usbus5 uhub0: on usbus5 uhub1 on usbus3 uhub1: on usbus3 uhub2 on usbus1 uhub2: on usbus1 uhub3 on usbus6 uhub3: on usbus6 uhub5 on usbus2 uhub5: on usbus2 uhub4 on usbus4 uhub4: on usbus4 -- Steve From owner-freebsd-current@freebsd.org Sat Jul 6 20:51:42 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B800C15D220F for ; Sat, 6 Jul 2019 20:51:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA5FA76920 for ; Sat, 6 Jul 2019 20:51:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9DB0726030B; Sat, 6 Jul 2019 22:51:38 +0200 (CEST) Subject: Re: Someone broke USB To: sgk@troutmask.apl.washington.edu Cc: freebsd-current@freebsd.org References: <20190706182301.GA45149@troutmask.apl.washington.edu> <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> <20190706194124.GA45536@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: <8ccf4066-7edc-e8c3-d669-16f649ec03c2@selasky.org> Date: Sat, 6 Jul 2019 22:50:59 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190706194124.GA45536@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CA5FA76920 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.41 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.53)[-0.535,0]; IP_SCORE(-2.56)[ip: (-9.08), ipnet: 2a01:4f8::/29(-1.94), asn: 24940(-1.78), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 20:51:42 -0000 On 2019-07-06 21:41, Steve Kargl wrote: > On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: >> On 2019-07-06 20:23, Steve Kargl wrote: >>> So, how does one get usb working, again? >>> >>> -- Steve >> >> Can you show dmesg? >> > > It looks like the enumeration of busses and devices has changed. > grepping for uhub and usbus of the working and broken dmesg.boot > gives > Are you able to bisect the commit introducing the bad behaviour? --HPS From owner-freebsd-current@freebsd.org Sat Jul 6 21:06:17 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A62DE15D26CF for ; Sat, 6 Jul 2019 21:06:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AF63D76F54 for ; Sat, 6 Jul 2019 21:06:15 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x66L6Dit045889 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jul 2019 14:06:13 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x66L6DJx045888; Sat, 6 Jul 2019 14:06:13 -0700 (PDT) (envelope-from sgk) Date: Sat, 6 Jul 2019 14:06:13 -0700 From: Steve Kargl To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: Someone broke USB Message-ID: <20190706210613.GA45709@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190706182301.GA45149@troutmask.apl.washington.edu> <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> <20190706194124.GA45536@troutmask.apl.washington.edu> <8ccf4066-7edc-e8c3-d669-16f649ec03c2@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ccf4066-7edc-e8c3-d669-16f649ec03c2@selasky.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: AF63D76F54 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.43 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.84)[0.838,0]; NEURAL_HAM_LONG(-0.44)[-0.437,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.15)[0.152,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[ip: (0.07), ipnet: 128.95.0.0/16(0.07), asn: 73(-0.13), country: US(-0.06)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 21:06:17 -0000 On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote: > On 2019-07-06 21:41, Steve Kargl wrote: > > On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: > >> On 2019-07-06 20:23, Steve Kargl wrote: > >>> So, how does one get usb working, again? > >>> > >>> -- Steve > >> > >> Can you show dmesg? > >> > > > > It looks like the enumeration of busses and devices has changed. > > grepping for uhub and usbus of the working and broken dmesg.boot > > gives > > > > Are you able to bisect the commit introducing the bad behaviour? > I'll give it a shot. I have two revision number to work with. -- Steve From owner-freebsd-current@freebsd.org Sat Jul 6 21:08:26 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E041015D27B7 for ; Sat, 6 Jul 2019 21:08:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31F00770A2 for ; Sat, 6 Jul 2019 21:08:25 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1562447298; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=RGI+dbPn68cgdPgRah3VRaPDsYfaGWEBaVR/tSRvIhJzcB4byoLYj12v7FmRq2UVWcZ7xHaEqJzMG 27sfiFjCeiNpgFshnH5SLSHbQ0se6Dy9YD3reqF9tSZ9B2bnbDHt2Cq9zBtpa9U262aqLUWtOoRFcf ruICUfeOjpP8Bc18kJY+1CLgNNkEQRpnfbGeoh8I00j0+L13dypD0xof+SuXExhOdlRIojGahHb6eP bCvdeBuS9IUJSlY1SbWDqUvvhXAD0Fct7EY7qRd1eFZhs0zCO1jNBTITRFrmLWVilywaUxDSFE6iDW clOx2BOsKgqfuibLGzdKIbtHnpoIk2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=wpqnXupWXuBkN6molwAR+4SvQzuwzOm1ZTuhKL+BSwo=; b=SYUSjYmyyFb+Y72V+96lEdmsHJG8zWyGEjxD276gV5dyqxk3QGaPs2cfRMv2MRMo1B8Hxd72HOIqf GM1Aoc5vyhTLeTnvarrEPpCA/lWVC3Fy1pMR5pq1DfLcvGCabIQx9i5rlBW4fyWP4umPuMVZVvgIIa WPWZKV8aMAY6CbdNQyCuZ9WliotM2AmRi0X8OAR4PqqXQ7OMIdRgBFIzpnwxntut3fcWzGdyXtFgMP oRuw6g42pU130O+KYAUG1qcOV103KdNfEOYPgKi5b3VjmOaf1OP3WUMwDaCXF7Xqvj9FK+QQxAMubQ MjXQmKB1IhrV/YIF230cNmTnP4D1kxw== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=wpqnXupWXuBkN6molwAR+4SvQzuwzOm1ZTuhKL+BSwo=; b=JjPPKfhzUGjCpY3B9kCqeqk1SXsaj/3bMI/q9kuJij8ugvaVQRHFqMDGvJa6s14Vg9xhr6luRqqb9 sGyh+xLWkfN28VfWXs1MMliE46eocPwYKGJpHkjvC3FW+40eWI4QGLMDvKdvhciKIensvQUzoLqHOL 4I+t4OWGd8QvtdvJhjEzgUN+zo1hOyxmqTWM5qw8IVvo5QIZjDJnwbSiQ3Qku4ZgV/IpXDPmyOfpfb K9Q7FSNZe0LJcbk/+9pup3AQBHv9g8RPGdkWIOoNSnASRA9wDUGa0ds71m9KJGibD2wFfdrJbLwWbV RH8MU66baS+DNwb0sKgzrxGRpLHwZjQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 2aefa648-a032-11e9-bed8-032691b1d9b0 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 2aefa648-a032-11e9-bed8-032691b1d9b0; Sat, 06 Jul 2019 21:08:17 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x66L8DfL097391; Sat, 6 Jul 2019 15:08:13 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <4d866257df0aa0a671973555b4a9a0eb27088d5c.camel@freebsd.org> Subject: Re: Someone broke USB From: Ian Lepore To: sgk@troutmask.apl.washington.edu, Hans Petter Selasky Cc: freebsd-current@freebsd.org Date: Sat, 06 Jul 2019 15:08:13 -0600 In-Reply-To: <20190706210613.GA45709@troutmask.apl.washington.edu> References: <20190706182301.GA45149@troutmask.apl.washington.edu> <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> <20190706194124.GA45536@troutmask.apl.washington.edu> <8ccf4066-7edc-e8c3-d669-16f649ec03c2@selasky.org> <20190706210613.GA45709@troutmask.apl.washington.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 31F00770A2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 21:08:26 -0000 On Sat, 2019-07-06 at 14:06 -0700, Steve Kargl wrote: > On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote: > > On 2019-07-06 21:41, Steve Kargl wrote: > > > On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky > > > wrote: > > > > On 2019-07-06 20:23, Steve Kargl wrote: > > > > > So, how does one get usb working, again? > > > > > > > > > > -- Steve > > > > > > > > Can you show dmesg? > > > > > > > > > > It looks like the enumeration of busses and devices has changed. > > > grepping for uhub and usbus of the working and broken dmesg.boot > > > gives > > > > > > > Are you able to bisect the commit introducing the bad behaviour? > > > > I'll give it a shot. I have two revision number to work with. > It seems almost certain to be r349161 that causes the problem. -- Ian From owner-freebsd-current@freebsd.org Sat Jul 6 21:46:08 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B20F015D3AD9 for ; Sat, 6 Jul 2019 21:46:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9EA481DCB; Sat, 6 Jul 2019 21:45:05 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 274AA26030B; Sat, 6 Jul 2019 23:45:01 +0200 (CEST) Subject: Re: Someone broke USB To: Ian Lepore , sgk@troutmask.apl.washington.edu Cc: freebsd-current@freebsd.org, takawata@FreeBSD.org References: <20190706182301.GA45149@troutmask.apl.washington.edu> <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> <20190706194124.GA45536@troutmask.apl.washington.edu> <8ccf4066-7edc-e8c3-d669-16f649ec03c2@selasky.org> <20190706210613.GA45709@troutmask.apl.washington.edu> <4d866257df0aa0a671973555b4a9a0eb27088d5c.camel@freebsd.org> From: Hans Petter Selasky Message-ID: <0758ce54-54af-ce27-a0e3-6a1d20f10bd0@selasky.org> Date: Sat, 6 Jul 2019 23:44:22 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <4d866257df0aa0a671973555b4a9a0eb27088d5c.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B9EA481DCB X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.01 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; NEURAL_HAM_SHORT(-0.13)[-0.134,0]; IP_SCORE(-2.56)[ip: (-9.09), ipnet: 2a01:4f8::/29(-1.94), asn: 24940(-1.78), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 21:46:09 -0000 Hi Takanori, Can you have a look at the issues reported in this thread? Are the ACPI functions you call thread safe? USB will enumerate multiple busses at the same time. --HPS On 2019-07-06 23:08, Ian Lepore wrote: > On Sat, 2019-07-06 at 14:06 -0700, Steve Kargl wrote: >> On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote: >>> On 2019-07-06 21:41, Steve Kargl wrote: >>>> On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky >>>> wrote: >>>>> On 2019-07-06 20:23, Steve Kargl wrote: >>>>>> So, how does one get usb working, again? >>>>>> >>>>>> -- Steve >>>>> >>>>> Can you show dmesg? >>>>> >>>> >>>> It looks like the enumeration of busses and devices has changed. >>>> grepping for uhub and usbus of the working and broken dmesg.boot >>>> gives >>>> >>> >>> Are you able to bisect the commit introducing the bad behaviour? >>> >> >> I'll give it a shot. I have two revision number to work with. >> > > It seems almost certain to be r349161 that causes the problem. > From owner-freebsd-current@freebsd.org Sat Jul 6 23:04:14 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D222715D5680 for ; Sat, 6 Jul 2019 23:04:13 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta02.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ACFED85115 for ; Sat, 6 Jul 2019 23:04:12 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id jtgEhgdox3JQGjtgGhzVo5; Sat, 06 Jul 2019 23:01:22 +0000 Received: from [192.168.1.100] (inspiron [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id x66N1HuF001404 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 6 Jul 2019 19:01:18 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host inspiron [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org Subject: Re: Someone broke USB To: freebsd-current@freebsd.org References: <20190706182301.GA45149@troutmask.apl.washington.edu> <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> <20190706194124.GA45536@troutmask.apl.washington.edu> <8ccf4066-7edc-e8c3-d669-16f649ec03c2@selasky.org> From: Thomas Laus Openpgp: preference=signencrypt Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= mQGiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthbQcVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPoh/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJcKgq6BQkhqyDOAAoJEOv/gtRiCDbP9xQAoL7B hCgFeI2K/0koKP3U8OB52nQyAJ0dd/QVJC7tV8gER4tse5GCUN5CHrkCDQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX64hmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAlwqCsMFCRhtvicACgkQ6/+C1GIINs/KCgCdGI1pg3HFhr7VEQeC63bhlMKH 0GAAn0mvTZY9OWKGMPoo0x/HdXkdgJHe Message-ID: <68644c37-2d9c-df23-8c1f-a8d2825d22e0@acm.org> Date: Sat, 6 Jul 2019 19:01:17 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <8ccf4066-7edc-e8c3-d669-16f649ec03c2@selasky.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGtkr6nb6zyREzcWLv6TrWY/d8VWjYqduXVdrCKX36RkGtQVe+tCLCH+ff8xatlTrGrf+xNw/1nq+2D7L4H9F9o7AQmHQNnF14jfCOWqOfn0MERzWCZ4 wdxvEj2BpA8GeRHH5BmKcDaStOkJ47zfb13TiUxDWN9Az/8cbnXCWlAc X-Rspamd-Queue-Id: ACFED85115 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=softfail (mx1.freebsd.org: 107.14.166.231 is neither permitted nor denied by domain of lausts@acm.org) smtp.mailfrom=lausts@acm.org X-Spamd-Result: default: False [-3.30 / 15.00]; HAS_REPLYTO(0.00)[lausts@acm.org]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mail.mailroute.net]; NEURAL_HAM_SHORT(-0.39)[-0.394,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.79)[ipnet: 107.14.160.0/20(-2.17), asn: 14065(-1.74), country: US(-0.06)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14065, ipnet:107.14.160.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[189.112.29.65.zen.spamhaus.org : 127.0.0.10]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[acm.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[231.166.14.107.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 23:04:14 -0000 On 2019-07-06 16:50, Hans Petter Selasky wrote: > > Are you able to bisect the commit introducing the bad behaviour? > I built and booted r349160. My 'boot mount waiting for USBUS7 -> USBUS0 issue went away but the startup halted at the 'mounting late filesystems' step of rc.conf. I had the USB issue at r349161 but building and loading the previous commit has other problems. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Sat Jul 6 23:14:57 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F16915D5C75 for ; Sat, 6 Jul 2019 23:14:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C6B685E1F; Sat, 6 Jul 2019 23:14:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x66NErX5046478 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Jul 2019 16:14:54 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x66NErtv046477; Sat, 6 Jul 2019 16:14:53 -0700 (PDT) (envelope-from sgk) Date: Sat, 6 Jul 2019 16:14:53 -0700 From: Steve Kargl To: Ian Lepore Cc: Hans Petter Selasky , freebsd-current@freebsd.org Subject: Re: Someone broke USB Message-ID: <20190706231453.GA46470@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190706182301.GA45149@troutmask.apl.washington.edu> <770bc251-7d0f-d56f-6b86-89245b79945f@selasky.org> <20190706194124.GA45536@troutmask.apl.washington.edu> <8ccf4066-7edc-e8c3-d669-16f649ec03c2@selasky.org> <20190706210613.GA45709@troutmask.apl.washington.edu> <4d866257df0aa0a671973555b4a9a0eb27088d5c.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d866257df0aa0a671973555b4a9a0eb27088d5c.camel@freebsd.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 1C6B685E1F X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [0.71 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.00)[-0.004,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.55)[-0.546,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.38)[0.381,0]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[ip: (0.07), ipnet: 128.95.0.0/16(0.07), asn: 73(-0.13), country: US(-0.06)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 23:14:57 -0000 On Sat, Jul 06, 2019 at 03:08:13PM -0600, Ian Lepore wrote: > On Sat, 2019-07-06 at 14:06 -0700, Steve Kargl wrote: > > On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote: > > > On 2019-07-06 21:41, Steve Kargl wrote: > > > > On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky > > > > wrote: > > > > > On 2019-07-06 20:23, Steve Kargl wrote: > > > > > > So, how does one get usb working, again? > > > > > > > > > > > > -- Steve > > > > > > > > > > Can you show dmesg? > > > > > > > > > > > > > It looks like the enumeration of busses and devices has changed. > > > > grepping for uhub and usbus of the working and broken dmesg.boot > > > > gives > > > > > > > > > > Are you able to bisect the commit introducing the bad behaviour? > > > > > > > I'll give it a shot. I have two revision number to work with. > > > > It seems almost certain to be r349161 that causes the problem. > I've backed out the change, and the buildkernel is currently running. It won't finish for an hour or so (old hardware and rebuilding another project). -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow