From owner-freebsd-hackers@freebsd.org Sun Apr 29 03:09:13 2018 Return-Path: Delivered-To: freebsd-hackers@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 BE2F4FC2563; Sun, 29 Apr 2018 03:09:13 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37AAB713BD; Sun, 29 Apr 2018 03:09:13 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id a137so6139734wme.1; Sat, 28 Apr 2018 20:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+0CR1fLqjfJ+zlBubMJwAfCujjl+6K1jE4ikdRfOIlU=; b=aFynqDQwSALWg6acHFWupAHrsOYISvQz7KqJ0hpxjSXyaDTtpFfd/WsUrwXFNZqNJy vJ/1auv/En1M7PHzqfOvBGKTvbJdZ9/votbsTQ9heTp0r4EJsfurWhK5Ny/fCcuMNeG6 FhCFWgFVRzcyvI3QCTTDE6AEkyDYRwwjpqZal89R38ea1hLyK4934bS327q8sPNsg6tE Vd6zsg29xOXUwQAxF3g5nnWobBuDacHmJdIDJt7INsQlXhcMCfJkJR+xEYQeYbkbGN19 aa6gGaa0EaZVpn0oHiOuoCPdVvIcWF6EpBPtET/K6CvXd6xzlQBwqjKqOnhkLWtAY9IA vWxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+0CR1fLqjfJ+zlBubMJwAfCujjl+6K1jE4ikdRfOIlU=; b=F9IMtV+lc3mWe5qsflrU3I5nqP/shM/qZ+OnAV//WwzyVkNKEKWldmnmEYGetgIAQ7 TmQ3diRj+b+J2XYk4g/tCKS6qd8fjkka1mabgdMTXdFq34073LoxTCBaT3DnzX6OUT3Z ZPMIZtBgvi4BWUPrdBeix/bAuwNUZkPRe719e9JQLaflW13tc3XEcOAfQgMZVddm7Lt5 3EmvDc5n8RMvmrsrxa8FhLBjab2ZzYHdCdPTjwOQdBduCuKTfqlq1VT9DGsYOGoAesfw QQLpHRImKr/Jag28nXLRy8m6lIgDVe+GeQsazFA3/bGHHhFaAONbhBEoEq7msqxWbRMF SZcw== X-Gm-Message-State: ALQs6tD/nlZ+ll6CAEGZkJaFdWPCH+pEZ/ERyUbEG7omE692agC+rVEy I+Xzc6l98RsTGWF1VAPjnryby0ih9SnmCi0GcY4= X-Google-Smtp-Source: AB8JxZqy2xU16D13mElxfuR+XQKA5vqdfGEaj9E7Udeif36cwwauxpBm7oc+TxohjRzXi+zS5/AbVSnHjvdtgeMu8Ic= X-Received: by 10.28.190.15 with SMTP id o15mr4745987wmf.104.1524971352113; Sat, 28 Apr 2018 20:09:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.171.232 with HTTP; Sat, 28 Apr 2018 20:08:31 -0700 (PDT) In-Reply-To: References: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> From: "Jack L." Date: Sat, 28 Apr 2018 20:08:31 -0700 Message-ID: Subject: Re: Can we please finally solve Dell's racadm for FreeBSD? Advice needed To: Nicolas Embriz Cc: "Peter G." , FreeBSD Hackers , freebsd-amd64@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 03:09:14 -0000 I manage a variety of Dell servers running FreeBSD, only 610 and 1950s work with racadm but everything that can be done with racadm can also be done with ipmitool. I just use ipmitool to get around instead of their proprietary racadm stuff. What functionality do you need from racadm and maybe I can give you an ipmitool equivalent? On Sat, Apr 28, 2018 at 6:54 AM, Nicolas Embriz wrote: > Regarding this topic I have a Dell Power 2900 that I could donate for > testing more in detail this issues. > > If interested please PM. > > Regards. > > On Sat, Apr 28, 2018 at 3:39 PM, Peter G. wrote: > >> Dear everybody, >> >> regarding: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201799 >> >> would somebody knowledgeable be kind enough to advice and/or help with >> bringing Dell racadm client/tools to FreeBSD? What is the problem with >> ipmi enumeration Dan mentioned on his commit? What is in the first place >> desired is local access to local hardware via standard racadm client. >> Local management is the "big kahuna" here. >> >> There were several attempts over the years, yet everything waned away >> without any solid results. Dell hardware is constantly mentioned on the >> lists or in the forums, so clearly many of us use it. I myself manage >> several Dell servers. The lack of local racadm for FreeBSD is daring. >> >> On my own and out of my pocket I will offer 50 EUR in Bitcoin to anybody >> who will solve the problem, i.e. provide a working racadm client which >> can access and manage local hardware. Of course anybody else is welcome >> to chime in. I am willing to put that in escrow with a trusted member of >> the community. Please let me know what to do. >> >> Many thanks! >> -- >> PG >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sun Apr 29 05:24:32 2018 Return-Path: Delivered-To: freebsd-hackers@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 81075FC6D09 for ; Sun, 29 Apr 2018 05:24:32 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27E2D6E99C for ; Sun, 29 Apr 2018 05:24:32 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x236.google.com with SMTP id i69-v6so2069849ybg.2 for ; Sat, 28 Apr 2018 22:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=JiSdxTGdysnvk4f2/kEXmydaexYCtm77ThNw7ztvRFI=; b=GRCVOOF6Vr7GdYmEGi0db0i5EvAiHB7mTq4LPXMHNQB9ZlHiwrKW9MJ3TYlvtEXY6r eNOvXbojZHTZrOlirEv1/kYSFMCgnfTv7oT7Etwqaczj0qf244cpGc2YA9dZvNXHD11w w+oIgLp2MoFqTSMCc5Qw+fboGwMdX3Fqi4umo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JiSdxTGdysnvk4f2/kEXmydaexYCtm77ThNw7ztvRFI=; b=fS0eBNM6P0eWSozWOVl/dTKKp0HRxnYAYN3GBlZOeqPVp2ffoVqwR0s47Og/UF1lO8 s2EY0uCDy8J0lmING9HSygw+vwy5nmnrGTVX4iXMFxaGNIWLt3WvhdHFqgM5/6XzLPIk x/o/nhQBaFQjHlWkjicknCstBVXtOHMD2M+WrSL6UeaCCoiPzvqlNQ9vzEEztNT5Ywr7 DyUQAXSFkhNRvi0MmoYhpuWYcTgEJjrLwXfTkjgGggyhVfskx9YVM5/+AwuKFrP+ZN51 AjRovu5g+z4ieekOWMnKhTYc03HjtxSi64gS7TrFlGVrA9rzpvt9NCUb5XulU+ixYa5J YBxg== X-Gm-Message-State: ALQs6tA9imS7jeLiviQBx0yKfc0a+M+rEJ2S0IV9Kw/Ld9vdOAiYP8ws hiXXZ1s1/08V44mvd8bbLbnq8F+zmf6t8QT0m3lQ9BSE X-Google-Smtp-Source: AB8JxZoc21iuW6Q/Dbrlmdqavwh5u5kc/Y14bgx50KqOCfE1XjrXJpvHoiW6Ri8ve3W76ulzmcLLfiG2kFgRwCmK72o= X-Received: by 2002:a25:5b0b:: with SMTP id p11-v6mr2994187ybb.338.1524979471238; Sat, 28 Apr 2018 22:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:c709:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 22:24:00 -0700 (PDT) From: Eitan Adler Date: Sat, 28 Apr 2018 22:24:00 -0700 Message-ID: Subject: "Sysctl as a Service" for influxdb / telegraf To: FreeBSD Hackers , Ed Schouten , daniel.nelson@influxdb.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 05:24:32 -0000 Resurrecting a somewhat old thread: I've been talking with the maintainer of telegraf about implementing an importer for the Prometheus exporter. They mentioned that they'd prefer a slightly different format. I'd like to add a new independent application similar to prometheus_sysctl_exporter for the influx wire format. Why independent? The set of options that each offer differ and the two formats will grow more different over time. For example prometheus supports descriptions, while influx support data types. Is there any objections to adding another application? If so, would a new output format for the existing binary be okay? References: Upstream issue: https://github.com/influxdata/telegraf/issues/4060 Proof of Concept: C code: https://ptpb.pw/At9H/c. I'm likely to factor out the common functions and include them as a single file when I commit. Original thread: https://lists.freebsd.org/pipermail/freebsd-hackers/2016-December/050283.html Wire format: https://docs.influxdata.com/influxdb/v1.5/write_protocols/line_protocol_tutorial/ -- Eitan Adler From owner-freebsd-hackers@freebsd.org Sun Apr 29 09:30:47 2018 Return-Path: Delivered-To: freebsd-hackers@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 A2046FA7B2B for ; Sun, 29 Apr 2018 09:30:47 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 119997F6F6 for ; Sun, 29 Apr 2018 09:30:46 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x22f.google.com with SMTP id r125-v6so8424566lfe.2 for ; Sun, 29 Apr 2018 02:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jgQGPkWXMpe0mND9CKWuHZjOULG879lqoXncPOvBD2M=; b=cB2XRt+cePR9gejCegb79HpIMFwPOk3HoRQK1P953pIoPeM0EduksOwNlEmwm69yWa eOLwVbFJCa1YAqcJ4QbWUjFHUvSMNXPcGQNjOmv8c/wVxW6BdJnGnTFu/uv4zGv5HT1I eGTcJlZ2Qb9Zs03GCFjwOzJnasxtCr+LD4jVYmIowqOum8EVwG+m5QYbgJoo8NhTLRit r0yg/kceTLDF0DPS+iLRFg0m9PphkehFh0b8hHL2zyBVsOnV1AFRIakIfEPW7Vm6M5v2 eK3ezh7nx3Lkaw3A6KXT8AXzlsTq9spddGDz4igOFbhf5OiJdV9Q07VRFSqL9vcS9MHL vt2A== 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=jgQGPkWXMpe0mND9CKWuHZjOULG879lqoXncPOvBD2M=; b=VVEKIOb8gsDXNk/08TDHpJVYckytmQD987nb6n2hC6pvrWkl1l4hNAkX3z6JK3nht9 lBI0dUqeSbIdpNqtxXCr4xuV7mW08I4mGlE14eyoMfZUw0kzH7D7TndoykoLsTDeSW9M RJkp8kut4yqMa0XeYQOov4pStOjrcwpkuTJoON0HmeC5S5kQHg+SESTTwc3utRzfkMAY U2LYdzy72LHVFL5f4CLDUJwt5wWomTuEu7Xwng75JxRpiJMXrOSyCiirdA6BULA5sT0U WdnmL/n93kdqpi8WQqzrqI372rRxjVbPHSYn3sBKvwhSjMDiz2IarWCfS25Mc1aAkWd0 JzsQ== X-Gm-Message-State: ALQs6tBiBtrgXKlxLurTzfYpzChvcv+Q+n51puvm8TY2jTuVM38PZRW4 cZnnB12Y3R7fUdXXE43PqeQQy1UsIW0QN/6IbD0WppEI X-Google-Smtp-Source: AB8JxZo/w9bba1fymtQTgZj9iig1B4iyh2XcLeiROa2IdTE2NcWtNEHPJxlnY+VbHXGCw9R5qiX+wX9keOVqvdIIH1E= X-Received: by 2002:a2e:25a:: with SMTP id 87-v6mr5825169ljc.46.1524994245105; Sun, 29 Apr 2018 02:30:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steven Hartland Date: Sun, 29 Apr 2018 09:30:33 +0000 Message-ID: Subject: Re: "Sysctl as a Service" for influxdb / telegraf To: Eitan Adler Cc: Ed Schouten , FreeBSD Hackers , daniel.nelson@influxdb.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 09:30:47 -0000 IMO if you were to add a new format the name of the binary should change too so it=E2=80=99s generic such as just sysctl_exporter. On Sun, 29 Apr 2018 at 06:27, Eitan Adler wrote: > Resurrecting a somewhat old thread: > > I've been talking with the maintainer of telegraf about implementing > an importer for the Prometheus exporter. They mentioned that they'd > prefer a slightly different format. I'd like to add a new independent > application similar to prometheus_sysctl_exporter for the influx wire > format. > > Why independent? The set of options that each offer differ and the two > formats will grow more different over time. For example prometheus > supports descriptions, while influx support data types. > > Is there any objections to adding another application? If so, would a > new output format for the existing binary be okay? > > References: > Upstream issue: https://github.com/influxdata/telegraf/issues/4060 > Proof of Concept: C code: https://ptpb.pw/At9H/c. I'm likely to factor > out the common functions and include them as a single file when I > commit. > Original thread: > > https://lists.freebsd.org/pipermail/freebsd-hackers/2016-December/050283.= html > Wire format: > https://docs.influxdata.com/influxdb/v1.5/write_protocols/line_protocol_t= utorial/ > > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sun Apr 29 11:47:59 2018 Return-Path: Delivered-To: freebsd-hackers@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 A5474FAA586 for ; Sun, 29 Apr 2018 11:47:59 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15DE17B351 for ; Sun, 29 Apr 2018 11:47:58 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-lf0-x233.google.com with SMTP id h197-v6so8618660lfg.11 for ; Sun, 29 Apr 2018 04:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sYpOko9m50lumJigM3ILPBNtJmzBVFwomuzryLCJ+Fo=; b=Ze1bg12u389u8UPNBAIh7/HYnZCK0S6BXDRnaeu3/FIWOIC45wXreW7yPhG8pEvwUv DAZ4D+OI9BpEz+E9/aOqpkojTAWhZJ3mgqjWvveVRMM6lfq/78L/p+eoO9LS5xXBZ+H+ pownj7y5QfG9ZLQtlsB1O9WnZNxEQqcYCUG2K5sMwoiVI6zyUCskj5f4vYO2cjiq5MH9 k4if+ZqprZCmyEU8xZVOd9B3L43ZkQl6KTvAENipe6klsunxVGoYxEtY8AOdMFx1daAm R3pNwFZTRXzMtHAwwSLhoQZ0CBVinnKgDBwpKbBVtnu9WzCZfgC2qTLekoSgqjDAdKTG 9S8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sYpOko9m50lumJigM3ILPBNtJmzBVFwomuzryLCJ+Fo=; b=ofR/FVKap1hqWxbk+8NQSFCor0Ve9VZPnk5blZ4LAv7pbwq6OPHYse0rQgxQLNApwZ ZW2EcESe2VpizAEmuFpDaq8haQT7/dc4cAohyHNyd8vqByZtgp3nMXv8m1hDbRU43zGd 0ANZpDQxRQsyMrX7GX5uViL/FH+Y2jU6ygtL+CqQDRyXWmxb3gG6y8Ay2S/8aP58HT5H WM8oFS4fHReZ+faGxJQppBBEDEzTwWNwxhLmfijDGiW8GuueCqafI8iz05MYtShhUyyR HZ8EkkKNtyLmLdnHZPMwDm7nQW4Oo969m2X/W4PNLsCNEEeaUmJH4XsFxQVSsM6+ZFdb 7LGg== X-Gm-Message-State: ALQs6tBI+Tn9LOkARxLIb6J1qJe/HTgFdmngd5r1fGWwuFvOrYSYidZN aZSzKh+tjrev4PGTxtPDO7fayB1tXEZ2K6JUbtXqeAKZ X-Google-Smtp-Source: AB8JxZol78hZ67tdIHiRIJntGL7f5A9hnw6jYigdfkH2xKsQQAP6jM7+Q1jmec9d4H9g+X0ukhZSvwe30IwPpAzw/ao= X-Received: by 2002:a19:e444:: with SMTP id b65-v6mr5057902lfh.61.1525002476677; Sun, 29 Apr 2018 04:47:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:294d:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 04:47:25 -0700 (PDT) In-Reply-To: References: From: Ed Schouten Date: Sun, 29 Apr 2018 13:47:25 +0200 Message-ID: Subject: Re: "Sysctl as a Service" for influxdb / telegraf To: Eitan Adler Cc: FreeBSD Hackers , daniel.nelson@influxdb.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 11:47:59 -0000 Hi Eitan. 2018-04-29 7:24 GMT+02:00 Eitan Adler : > I've been talking with the maintainer of telegraf about implementing > an importer for the Prometheus exporter. They mentioned that they'd > prefer a slightly different format. Not that I want to block any progress, maybe it makes sense to point the maintainer of Telegraf here: https://github.com/RichiH/OpenMetrics Apparently, the PrometheusDB, Influx and Monarch/Stackdriver authors (see CONTRIBUTORS.md) are working on standardising the Prometheus metrics format. Maybe it makes sense for the Telegraf developers to join that effort? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands From owner-freebsd-hackers@freebsd.org Sun Apr 29 14:28:18 2018 Return-Path: Delivered-To: freebsd-hackers@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 865E9FAE2C3; Sun, 29 Apr 2018 14:28:18 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) (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 215C27DD49; Sun, 29 Apr 2018 14:28:17 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 1FD0629661; Sun, 29 Apr 2018 16:28:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1525012090; bh=3da/vyZVt3DoKosDOv8yNZ6N2ytCYsoGiadblrQPqhM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=i18h2DNm4PMch6WX8jyjHltzhOLrVSMsmvkjM0wzWb5OiBLHwVDCnsA6YEy32mHJf oYraOcjoSVsaFkXcHFP97P0i5M1sSN8F1tW50U8fumRE9dsG3maEwHas3TAemmh4Bu +DOBnrCbL0+lUyKEgeksNfAt48DST/MEqY1IGQ+YgoDx9vfdThxeKSCW2JNmhlqT6T EKi4DdqFXDT5H13FP+gynguHOXjV9MNt+eM4yUAe261Tp4CxdsyyG7l2Nw0Wq7Cc78 PVnM7FBgGwEYAQ3rcyeexKMy5tODqvQMLNJaE/nNLZ6AhGsjRN8A8+q6ThL+8tXlKs LAq4FrDzFKcJw== X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (mail01.disroot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5xE5zeMqGGP; Sun, 29 Apr 2018 16:28:08 +0200 (CEST) Subject: Re: Can we please finally solve Dell's racadm for FreeBSD? Advice needed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1525012088; bh=3da/vyZVt3DoKosDOv8yNZ6N2ytCYsoGiadblrQPqhM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=GMexQlyDWAW7/Etoi0xRaOF/O2uTgBmQEqwCbZvR2qG5Ub5J3aJjC1A4D9T08Lr8Z v2hEqLgeoe9I7mPNLwHiCbRvmmzpOiJP3dqU3Cb83DK1zxXLUa25UNBW+YNH7je4k1 w8GED1FLBt3r5inWfl12mHzyfzBLEre5YvLFf/OYl/Vq4yEXz8OYF6C9gaqDlEucj5 RZWs9Ny7Plu7zqUOOy6avq8XQy30WPlskmo7l2aYkCrW54OhJFopPPqbzM9Q0aBgQ6 NJLQGqVKhjdbFgE8C3sxomWOQIAqC4n/EQLOSQ2JTef2bG/2poOzIAXFGowZwQvivX uqwggiOrBTHtg== To: xxjack12xx@gmail.com Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org, freebsd-hardware@freebsd.org References: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> From: "Peter G." Message-ID: Date: Sun, 29 Apr 2018 16:28:06 +0200 Mime-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 14:28:18 -0000 On 29/04/2018 05:08, Jack L. wrote: > I manage a variety of Dell servers running FreeBSD, only 610 and 1950s > work with racadm but everything that can be done with racadm can also > be done with ipmitool. I just use ipmitool to get around instead of > their proprietary racadm stuff. What functionality do you need from > racadm and maybe I can give you an ipmitool equivalent? It seems I may missed the ipmi angle altogether assuming it was only remote. Only now following Dan's comments I am realizing how racadm works talking to local hardware. You mean using this impi(4) as a local device and talking to it via local tool allowing coms with the device? Oh, that would do nicely. I need this for scripting mostly, e.g. monitoring what the intrusion sensor shows. Can you please describe your setup? What other kernel modules and 3rd party software do you employ? Any tricks with device.hints are needed? I have a small R220 at hand for testing, but it's lacking impi(4) altogether. Will have to rebuild. -- PG From owner-freebsd-hackers@freebsd.org Sun Apr 29 14:29:27 2018 Return-Path: Delivered-To: freebsd-hackers@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 80B90FAE3A1; Sun, 29 Apr 2018 14:29:27 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 1BB447DE84; Sun, 29 Apr 2018 14:29:27 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 823ED2814A; Sun, 29 Apr 2018 16:29:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgASCmEvMonn; Sun, 29 Apr 2018 16:29:23 +0200 (CEST) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id C859D28147; Sun, 29 Apr 2018 16:29:22 +0200 (CEST) Subject: Re: Getting ZFS pools back. To: Richard Yao Cc: FreeBSD Hackers , FreeBSD Filesystems References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> From: Willem Jan Withagen Message-ID: Date: Sun, 29 Apr 2018 16:29:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 14:29:27 -0000 On 28/04/2018 20:43, Richard Yao wrote: > What is the output of ‘zpool import‘ with no arguments? If I boot thru aa mem-stick.... # zpool import # So, empty line In the mean time I rebuild the system. Was able to retreive the data by a convoluted incantation of 'zpool import -fmNF' or something like that. Made a full backup, and started fresh. --WjW >> On Apr 28, 2018, at 11:42 AM, Willem Jan Withagen wrote: >> >> >> Hi, >> >> I had this server crash on me, and first it just complained about not being able to boot because it could not find the guid. >> >> Now I cannot even import the pools any longer. >> Althoug zdb -l /dev/ada0 still gives me data that indicates that there should be a ZFS pool on that partition. >> >> Any suggestions on how to get the pools/data back online? >> >> Help would be highly appreciated, since restoring it from backups is going to quite some work. >> >> Thanx, >> --WjW >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sun Apr 29 14:40:52 2018 Return-Path: Delivered-To: freebsd-hackers@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 7A505FAEB72; Sun, 29 Apr 2018 14:40:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00FE380D3B; Sun, 29 Apr 2018 14:40:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id m18-v6so8962889lfb.0; Sun, 29 Apr 2018 07:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+E4MjoDmPCpiOuF8DaCb5DcLt+yjN5KizG0ElaN+qAI=; b=g+FL8ihMfx9S4BuSv0zwuQO7ouHkfzxpz9b0U+CnxEjOC5k0E/KdhAnVYR4fQBTRcE hG2/RXzX5cxCfZqmkEGxzPI6Ku4r43owd9hdrM0lOeHwukk95dVwZYaerujDZ4xbwWN5 ku2dWEMpd93/jz59i9T6tPeHXxm7hRDiZ4SB3Jn/PfwG4QyusM+xGsVaGyVkLM1pFZ7J wWOza5/LGCe7v3gVW91AWejlWffnEgClM04hCOFEPafJZbLd+gfcZlWvTSe8W0qTGZcM d+HzSPMgR6XPjtpp0W4HjJGasVa0hONBZlPN1PBjTC8QVBEHlY6IEnZLfVu76rUfsg6k ovyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+E4MjoDmPCpiOuF8DaCb5DcLt+yjN5KizG0ElaN+qAI=; b=EceIGJwJENZj5DYoH3pvGQkmdcoaEXaj1JukabtRmaacm6tDgJRKhj12kLahg9oPPd im+avPp9JvW6ShGtZZQMCeWDMSJH0cIsSxyS7//ygG4tRSms4/KqLda84uBmq+C5bnpp I3D9AnCl3ofhbTahdLJWhJL4Q4Q+YVni7kFeMN5wYQ6Rk9yxSwAPE1XABG27yCquXgKt oUheOaJv+8Fk6zYx1SyOxrhp05ZdTC5LDbGIfVLTPFbSufg5I1GItQXFsowLAWvGd6pB qGTJ5tAQOUBfKURB3LSG7HSCkpspwg8qT8Bit8TQzCq8ZH78c662iYm2vdL6yGnfyNm3 OhZA== X-Gm-Message-State: ALQs6tAoyvVjndNvQENm7fg1JlgOX4uvf1mi7UI0BND4YLy/J0l3wEf/ mnB7iCSjeT7XxAO21o2sQbFMmcIsAKmgFBM6E+c= X-Google-Smtp-Source: AB8JxZp5T+/Et2dtDU41VT5tF5YHE4XH8AXEVbQf4Or57w8h7azY6cbxmJmVo53tBPs8bFducNZajrh11B2LmNST0j4= X-Received: by 2002:a2e:9f03:: with SMTP id u3-v6mr5866932ljk.53.1525012850386; Sun, 29 Apr 2018 07:40:50 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.114.79 with HTTP; Sun, 29 Apr 2018 07:40:49 -0700 (PDT) In-Reply-To: References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> From: Alan Somers Date: Sun, 29 Apr 2018 08:40:49 -0600 X-Google-Sender-Auth: yBDCKqGUP-1u390c2CtLNYMiSE4 Message-ID: Subject: Re: Getting ZFS pools back. To: Willem Jan Withagen Cc: Richard Yao , FreeBSD Filesystems , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 14:40:52 -0000 So your kernel couldn't find the pool. That might be due to a GEOM module that wasn't loaded but should've been (were you using gmirror or geli or something?). Or you might've accidentally destroyed the pool. It would still show up in "zdb -l", albeit in the destroyed state. Or you might've accidentally destroyed the partition. If the pool had resided on the disk's last partition, then "zdb -l /dev/ada0" still would've seen the label, since there's a copy of the label at the end of the device. But if you've reused the disk, then there's no way to know for sure. -Alan On Sun, Apr 29, 2018 at 8:29 AM, Willem Jan Withagen wrote: > On 28/04/2018 20:43, Richard Yao wrote: > >> What is the output of =E2=80=98zpool import=E2=80=98 with no arguments? >> > > If I boot thru aa mem-stick.... > # zpool import > # > > So, empty line > In the mean time I rebuild the system. > > Was able to retreive the data by a convoluted incantation of > 'zpool import -fmNF' or something like that. > Made a full backup, and started fresh. > > --WjW > > > > On Apr 28, 2018, at 11:42 AM, Willem Jan Withagen wrote= : >>> >>> >>> Hi, >>> >>> I had this server crash on me, and first it just complained about not >>> being able to boot because it could not find the guid. >>> >>> Now I cannot even import the pools any longer. >>> Althoug zdb -l /dev/ada0 still gives me data that indicates that there >>> should be a ZFS pool on that partition. >>> >>> Any suggestions on how to get the pools/data back online? >>> >>> Help would be highly appreciated, since restoring it from backups is >>> going to quite some work. >>> >>> Thanx, >>> --WjW >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@f >>> reebsd.org" >>> >> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sun Apr 29 15:20:50 2018 Return-Path: Delivered-To: freebsd-hackers@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 07186FAFD38 for ; Sun, 29 Apr 2018 15:20:50 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9837E6AB82 for ; Sun, 29 Apr 2018 15:20:49 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x230.google.com with SMTP id x145-v6so1458837ybg.10 for ; Sun, 29 Apr 2018 08:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/7cwG3aNKIg7jnHkp6r1VYg81VNSDFg2PQsQB6UERNA=; b=ujphqQ3vbhsnR0qoirnEUNJuyENBnbrTYWh+PL5vLNR6TiH7wTGe7HCHSrxA+DwCd4 iw5M+wqAZ9K28xzrQpDHr++WbS5jmIsqi0EzxcJvTFW6xUwwN1hfMqqYURoeQLl12S61 1iAHGGx7+QERpp5fgI6cIIWRZfaFc9/3o5m4w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/7cwG3aNKIg7jnHkp6r1VYg81VNSDFg2PQsQB6UERNA=; b=We7ka2qVUPUJd0UL72cSXCBPDmuqBTYCda5fDFNNKThvi5CBklbygX+zxDBKcdW/9t Q0rW6Q1crbnkPUbZRMG7SaJAYe0w0MiWH3RD2eyhD7FP5uWnlbaUnqcsCLzc/toLNB18 OCiiqS4pF5DCLzOVfh4SzazE0/e3UaiZlMwX9M4uB7vMlBv6TQ3jfMB2QjgN00rsCZ9F 5EcD35DmLKP5qC7pMOnEDz3DAtFWn9q2xbmPta/WUWIHMsJifa/9crclkXUwca8EV77p ZXlP8WL4uwvzscC8sQWKNGCvucroVcXgPGcNvJ0Gj7UdyFNAgYkJDEJ3uozTDsXmr+zp ZIDQ== X-Gm-Message-State: ALQs6tDYt+EM2Cxt/lW3EMVs511zM9wevQAviSIoykOGd6ltV0kSULoQ nW8RFJg8YTFPXOnZjDfXLqT/rfN0eNmZ72qLcxvAbg== X-Google-Smtp-Source: AB8JxZqIyb1kdDKpROD+/jjaLlRSXyMiitoB8rtmOBjsGqUjh7JbCFlZj6lMAz6VOFF3uWj7eTWzYDQaSoLJfeWiRso= X-Received: by 2002:a25:5b0b:: with SMTP id p11-v6mr3747706ybb.338.1525015248745; Sun, 29 Apr 2018 08:20:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:c709:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 08:20:18 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Sun, 29 Apr 2018 08:20:18 -0700 Message-ID: Subject: Re: "Sysctl as a Service" for influxdb / telegraf To: Ed Schouten Cc: FreeBSD Hackers , daniel.nelson@influxdb.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 15:20:50 -0000 On 29 April 2018 at 04:47, Ed Schouten wrote: > Hi Eitan. > > 2018-04-29 7:24 GMT+02:00 Eitan Adler : >> I've been talking with the maintainer of telegraf about implementing >> an importer for the Prometheus exporter. They mentioned that they'd >> prefer a slightly different format. > > Not that I want to block any progress, maybe it makes sense to point > the maintainer of Telegraf here: > > https://github.com/RichiH/OpenMetrics > > Apparently, the PrometheusDB, Influx and Monarch/Stackdriver authors > (see CONTRIBUTORS.md) are working on standardising the Prometheus > metrics format. Maybe it makes sense for the Telegraf developers to > join that effort? Influx and Telegraf are developed by the same company. They are also CCed on email. I'll let them reply with their thoughts -- Eitan Adler From owner-freebsd-hackers@freebsd.org Sun Apr 29 17:27:22 2018 Return-Path: Delivered-To: freebsd-hackers@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 A15ABFB28F8; Sun, 29 Apr 2018 17:27:22 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 309FA80FE0; Sun, 29 Apr 2018 17:27:22 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 8650E3D573; Sun, 29 Apr 2018 19:27:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0qfoFa_30An; Sun, 29 Apr 2018 19:27:13 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 211FC3D572; Sun, 29 Apr 2018 19:27:13 +0200 (CEST) Subject: Re: Getting ZFS pools back. To: Alan Somers Cc: Richard Yao , FreeBSD Filesystems , FreeBSD Hackers References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> From: Willem Jan Withagen Message-ID: <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> Date: Sun, 29 Apr 2018 19:27:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 17:27:22 -0000 On 29-4-2018 16:40, Alan Somers wrote: > So your kernel couldn't find the pool.  That might be due to a GEOM > module that wasn't loaded but should've been (were you using gmirror or > geli or something?).  Or you might've accidentally destroyed the pool. > It would still show up in "zdb -l", albeit in the destroyed state.  Or > you might've accidentally destroyed the partition.  If the pool had > resided on the disk's last partition, then "zdb -l /dev/ada0" still > would've seen the label, since there's a copy of the label at the end of > the device.  But if you've reused the disk, then there's no way to know > for sure. Hi Alan, I still have one of the original disks of the mirror, but the system/hardware causing trouble is back in use in the DC. No geli, or anything other that basic GEOM was involved. Disks were running on GPT: boot swap zroot zfsdata And yes zdb -l was able to find both pools: zroot, and zfsdata. And I'm pretty sure I did not destroy them on purpose. ;-) Trouble started when I installed (freebsd-update) 11.1 over a running 10.4. Which is sort of scarry? But because the system needed to go back on the air, I did only so much to recover the original stuff. But it just kept naging me over the GUID it could not find. So for sake of progress I reinstalled the system on one of the mirror disks, keeping the other one. So I could hook that disk up to my Freetest play box, and see what that brings. If anyone is interested. But than again the zpool import could have fixed what was broken in the first place. Haven't looked at it yet, since the 12 hour straight session yesterday was enough for the weekend. --WjW > -Alan > > On Sun, Apr 29, 2018 at 8:29 AM, Willem Jan Withagen > wrote: > > On 28/04/2018 20:43, Richard Yao wrote: > > What is the output of ‘zpool import‘ with no arguments? > > > If I boot thru aa mem-stick.... > # zpool import > # > > So, empty line > In the mean time I rebuild the system. > > Was able to retreive the data by a convoluted incantation of > 'zpool import -fmNF' or something like that. > Made a full backup, and started fresh. > > --WjW > > > > On Apr 28, 2018, at 11:42 AM, Willem Jan Withagen > > wrote: > > > Hi, > > I had this server crash on me, and first it just complained > about not being able to boot because it could not find the guid. > > Now I cannot even import the pools any longer. > Althoug zdb -l /dev/ada0 still gives me data that indicates > that there should be a ZFS pool on that partition. > > Any suggestions on how to get the pools/data back online? > > Help would be highly appreciated, since restoring it from > backups is going to quite some work. > > Thanx, > --WjW From owner-freebsd-hackers@freebsd.org Sun Apr 29 18:03:52 2018 Return-Path: Delivered-To: freebsd-hackers@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 735DFFB3636 for ; Sun, 29 Apr 2018 18:03:52 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 9600187EDC for ; Sun, 29 Apr 2018 18:03:51 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: (qmail 24356 invoked by uid 89); 29 Apr 2018 17:57:08 -0000 Received: from c-24-0-179-87.hsd1.nj.comcast.net (HELO iMac.local) (jan@digitaldaemon.com@24.0.179.87) by digitaldaemon.com with SMTP; 29 Apr 2018 17:57:08 -0000 Subject: Re: Getting ZFS pools back. To: Willem Jan Withagen , Alan Somers Cc: FreeBSD Filesystems , FreeBSD Hackers , Richard Yao References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> From: Jan Knepper Message-ID: <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> Date: Sun, 29 Apr 2018 13:57:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 18:03:52 -0000 On 04/29/2018 13:27, Willem Jan Withagen wrote: > Trouble started when I installed (freebsd-update) 11.1 over a running > 10.4. Which is sort of scarry? This does sounds 'scary' as I am planning to do this in the (near) future... Has anyone else experienced issues like this? Generally I do build the new system software on a running system, but then go to single user mode to perform the actual install. I have done many upgrades like that over 18 or so years and never seen or heard of an issue alike this. Thanks! ManiaC++ Jan Knepper From owner-freebsd-hackers@freebsd.org Sun Apr 29 18:21:21 2018 Return-Path: Delivered-To: freebsd-hackers@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 B6F4FFB4129 for ; Sun, 29 Apr 2018 18:21:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5B06D7BE for ; Sun, 29 Apr 2018 18:21:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id p3-v6so7603895itc.0 for ; Sun, 29 Apr 2018 11:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uABNZlQvDTp99jAU0v/nbxCtH4T5u38kO+tuOl5zvH8=; b=yZPVXaXgSzpTdA4IjfpjuzIEeEOifcJQ9RPJXlvLaUY2TByF9sJGEGYQfZAlt/vGsf eimtteFiq/J2+cUeexeCsJn34WRF52ZazyvUMURATmjpajXmq+HILBlByCaZSfvAQUv0 6guabEV6NSPQgKEtDfH9h+aE0SYvT2lmIUXDWRJBVCLoqcrRwmnmCJHYO5EzPu2a/4aR wa5Gqrm0OWt6rUZF7Ia9/OY7BNamaHQqiXrygNxiViBC9TRRYoeNRxdBkLbBQP/joeHR cwnD9S/9m4JpjIPc+WC1c/GYxQx/z4IEhtgr4o7HrfcJj309z5Rb7ildQ3oo+KDoB5vA 3www== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uABNZlQvDTp99jAU0v/nbxCtH4T5u38kO+tuOl5zvH8=; b=mVQRaKgJ5RojVpOKgyYswN7pc66SPTyA9oMSGMshHrlBgaWZYdzQa+jPS2PHPXRJxz q7KQXwPKQJp1AC9ZBquKfYf2QBii8st8Ubkp/u21VQtP+iYgt/RYuE/MTnONrr/ZHtU7 rz6OsPSbpLKCYp3YahfJnKeNWntEO/qm4V9asU+gagSLLlz5LQ154eOivds6oj6VK/H9 zceUXFyBkR4IaEdSByNzECf56j+K/A5VE4DjaZqVzErgPR3SkHLNZCKTkU+/waxrX6AA ZwO2wPZoMLEmeSN9nFip37CUb2U59hQReJ86Y7jrgj2xo+JoZ/JrbG9szIFk1pa3ZUzl iaqg== X-Gm-Message-State: ALQs6tADDoQF8dgvvpbxixsgSNGFymKtXycd7ixlzU/Mihal4/6OJ+gQ ji5aoUBLGrZ8eWwmPleiDAQD9Ky5Cs6+IS8ptlIMCA== X-Google-Smtp-Source: AB8JxZqANCpXB7sMqxVnhd+G8Lvnkji1U6D7EyzJV8ml3N7IIO5sYa7++hXdj4nbsnJRjvZ91O/i+rZimOOL3VeR38E= X-Received: by 2002:a24:42c6:: with SMTP id i189-v6mr9343932itb.73.1525026080498; Sun, 29 Apr 2018 11:21:20 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 11:21:19 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> From: Warner Losh Date: Sun, 29 Apr 2018 12:21:19 -0600 X-Google-Sender-Auth: pkzFlqKdzugInV083a6N0Rw8uwQ Message-ID: Subject: Re: Getting ZFS pools back. To: Jan Knepper Cc: Willem Jan Withagen , Alan Somers , FreeBSD Filesystems , FreeBSD Hackers , Richard Yao Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 18:21:22 -0000 On Sun, Apr 29, 2018 at 11:57 AM, Jan Knepper wrote: > On 04/29/2018 13:27, Willem Jan Withagen wrote: > >> Trouble started when I installed (freebsd-update) 11.1 over a running >> 10.4. Which is sort of scarry? >> > This does sounds 'scary' as I am planning to do this in the (near) > future... > > Has anyone else experienced issues like this? > > Generally I do build the new system software on a running system, but then > go to single user mode to perform the actual install. > > I have done many upgrades like that over 18 or so years and never seen or > heard of an issue alike this. 11.x binaries aren't guaranteed to work with a 10.x kernel. So that's a bit of a problem. freebsd-update shouldn't have let you do that either. However, most 11.x binaries work well enough to at least bootstrap / fix problems if booted on a 10.x kernel due to targeted forward compatibility. You shouldn't count on it for long, but it generally won't totally brick your box. In the past, and I believe this is still true, they work well enough to compile and install a new kernel after pulling sources. The 10.x -> 11.x syscall changes are such that you should be fine. At least if you are on UFS. However, the ZFS ioctls and such are in the bag of 'don't specifically guarantee and also they change a lot' so that may be why you can't mount ZFS by UUID. I've not checked to see if there's specifically an issue here or not. The ZFS ABI is somewhat more fragile than other parts of the system, so you may have issues here. If all else fails, you may be able to PXE boot an 11 kernel, or boot off a USB memstick image to install a kernel. Generally, while we don't guarantee forward compatibility (running newer binaries on older kernels), we've generally built enough forward compat so that things work well enough to complete the upgrade. That's why you haven't hit an issue in 18 years of upgrading. However, the velocity of syscall additions has increased, and we've gone from fairly stable (stale?) ABIs for UFS to a more dynamic one for ZFS where backwards compat is a bit of a crap shoot and forward compat isn't really there at all. That's likely why you've hit a speed bump here. Warner From owner-freebsd-hackers@freebsd.org Sun Apr 29 18:31:35 2018 Return-Path: Delivered-To: freebsd-hackers@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 7E504FB46DC for ; Sun, 29 Apr 2018 18:31:35 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 15BDD705BE for ; Sun, 29 Apr 2018 18:31:34 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: (qmail 28614 invoked by uid 89); 29 Apr 2018 18:31:31 -0000 Received: from c-24-0-179-87.hsd1.nj.comcast.net (HELO iMac.local) (jan@digitaldaemon.com@24.0.179.87) by digitaldaemon.com with SMTP; 29 Apr 2018 18:31:31 -0000 Subject: Re: Getting ZFS pools back. To: Warner Losh Cc: Willem Jan Withagen , Alan Somers , FreeBSD Filesystems , FreeBSD Hackers , Richard Yao References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> From: Jan Knepper Message-ID: <5692d3b6-038e-4c4b-c5b6-b0f719b4ac38@digitaldaemon.com> Date: Sun, 29 Apr 2018 14:31:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 18:31:35 -0000 On 04/29/2018 14:21, Warner Losh wrote: > On Sun, Apr 29, 2018 at 11:57 AM, Jan Knepper > wrote: > > On 04/29/2018 13:27, Willem Jan Withagen wrote: > > Trouble started when I installed (freebsd-update) 11.1 over a > running 10.4. Which is sort of scarry? > > This does sounds 'scary' as I am planning to do this in the (near) > future... > > Has anyone else experienced issues like this? > > Generally I do build the new system software on a running system, > but then go to single user mode to perform the actual install. > > I have done many upgrades like that over 18 or so years and never > seen or heard of an issue alike this. > > > 11.x binaries aren't guaranteed to work with a 10.x kernel. So that's > a bit of a problem. freebsd-update shouldn't have let you do that either. The process I have used so far is to svnup, build, reboot... > However, most 11.x binaries work well enough to at least bootstrap / > fix problems if booted on a 10.x kernel due to targeted forward > compatibility. You shouldn't count on it for long, but it generally > won't totally brick your box. In the past, and I believe this is still > true, they work well enough to compile and install a new kernel after > pulling sources. The 10.x -> 11.x syscall changes are such that you > should be fine. At least if you are on UFS. > > However, the ZFS ioctls and such are in the bag of 'don't specifically > guarantee and also they change a lot' so that may be why you can't > mount ZFS by UUID. I've not checked to see if there's specifically an > issue here or not. The ZFS ABI is somewhat more fragile than other > parts of the system, so you may have issues here. > > If all else fails, you may be able to PXE boot an 11 kernel, or boot > off a USB memstick image to install a kernel. > > Generally, while we don't guarantee forward compatibility (running > newer binaries on older kernels), we've generally built enough forward > compat so that things work well enough to complete the upgrade. That's > why you haven't hit an issue in 18 years of upgrading. However, the > velocity of syscall additions has increased, and we've gone from > fairly stable (stale?) ABIs for UFS to a more dynamic one for ZFS > where backwards compat is a bit of a crap shoot and forward compat > isn't really there at all. That's likely why you've hit a speed bump here. > I have not closely looked at the procedures outlined in /usr/src/UPDATING for 11.x. But do I read correctly that performing a buildworld, buildkernel, then installworld and reboot to update from 10.4 to 11.x does not work? Thanks! ManiaC++ Jan Knepper From owner-freebsd-hackers@freebsd.org Sun Apr 29 18:32:50 2018 Return-Path: Delivered-To: freebsd-hackers@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 04422FB477E; Sun, 29 Apr 2018 18:32:50 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 9086770706; Sun, 29 Apr 2018 18:32:49 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 1B18D3DFB2; Sun, 29 Apr 2018 20:32:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeiTaFAUhDC3; Sun, 29 Apr 2018 20:32:46 +0200 (CEST) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 58EF73DFAE; Sun, 29 Apr 2018 20:32:46 +0200 (CEST) Subject: Re: Getting ZFS pools back. To: Jan Knepper , Alan Somers Cc: FreeBSD Filesystems , FreeBSD Hackers , Richard Yao References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> From: Willem Jan Withagen Message-ID: <31f9e4cd-4865-651a-0966-4600101beb8f@digiware.nl> Date: Sun, 29 Apr 2018 20:32:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 18:32:50 -0000 On 29/04/2018 19:57, Jan Knepper wrote: > On 04/29/2018 13:27, Willem Jan Withagen wrote: >> Trouble started when I installed (freebsd-update) 11.1 over a running >> 10.4. Which is sort of scarry? > This does sounds 'scary' as I am planning to do this in the (near) > future... > > Has anyone else experienced issues like this? > > Generally I do build the new system software on a running system, but > then go to single user mode to perform the actual install. > > I have done many upgrades like that over 18 or so years and never seen > or heard of an issue alike this. Hi Jan, Most of my upgrades went smooth, other than being pestered by files that are only changed in verssion no and/or comments. This is a rather old server that I installed zfs-on-root, when there were only howtos and no automagic installers. So I guess that it might even be from the 9.x days. It went through several manual upgrades and at least once a online disk replacement with growing disks (500G to 4T). Al that went well, but could very well be that some odd bits and pieces were (missing) left overs. So Don't excluded that there is pilot error involved. I tried Google to find more about fixing the system when this error got reported, but only a rather hefty session with Andriy Gapon, I think. And that was for 9.x or so. Nothing else... So given my need to go on, I just reinstalled. --WjW From owner-freebsd-hackers@freebsd.org Sun Apr 29 18:34:08 2018 Return-Path: Delivered-To: freebsd-hackers@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 E877FFB4854 for ; Sun, 29 Apr 2018 18:34:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4954B7082D for ; Sun, 29 Apr 2018 18:34:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id e20-v6so7966803iof.4 for ; Sun, 29 Apr 2018 11:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BaNki7abp+a/BZuXxYzg6EGbIz9W1/HBg1D5jZGc7jI=; b=XR72VzL6S3vSDGEg4m0gSavWLjw6yqGBombQ48vv0Y7t7IrEfREIGB1qc2LrGeDKWM 4JkYunpxCtRhHvyinjUJbxryH6P1idVMzcbcmQ/VWZOwcNJmKRkqIN4TsBLJbIvzSMDE nIge6L0J+OhCxPdGwKKnLS7f0rZ4IwqZWpf5PiXbqSM+hvVwQtjkyUrWOsh9Q4e9sYBD ni/K7olkgR9ZhbmT3unxIRap4S0VCDKK6APyg+YRy2NeYgRNo9hpjlm+doDDmyqySwdT IlpEq7C6PPYlXXazlVimWSfngVoEhPfPZ5DKsuoix6pG1AxJtkUPDmFxuOZLPGUf4ZZh Xj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BaNki7abp+a/BZuXxYzg6EGbIz9W1/HBg1D5jZGc7jI=; b=LTxb2ydtTA6hZisz29sr0CGXmwsNDest23wfWtHYWhiI1BEQJSczOsiCtFwxUs+zwf 61x4VeA6+o9lWYKElvfBdRhkzV4LcNnOsfftRpb+0+uYD43C7mPpuHy1h5koRPWf2MKe +FBt0r19HZm6sjzgnCDcUQKRHB7AiT3kK6FVIU43/tpWvotikFn3YNC/v4TGG3KGhCkG bxvtSWdJne9ePwrvtpR+XTCoh1nuP/w8j2LCs9do+czsmqiBegArMlaaEdwu0C7tKEMJ yRzebG0WIHn1KmomitzjUsH+bro91e7SwQVnm+ZKE7/Nn4r1/NO6XrYt8PgzQjVL+FVU Iv/A== X-Gm-Message-State: ALQs6tAUuSShmHN1mToAfs6z7witMmgVATanm1FZATTHIJvk+KcDzRu0 C0ajAihFdO7bPjUgHQqZkKvC3FA/PUfn5O7rMh3VPg== X-Google-Smtp-Source: AB8JxZow7PoPmhek7TqiAXS9wwOgfkLIBPTnKB2XIR75Z5k16nng4+aDNbhUE07HB+O78f8Nq9q7dPnAwhgiJDQed2Y= X-Received: by 2002:a6b:d404:: with SMTP id l4-v6mr10065025iog.37.1525026846533; Sun, 29 Apr 2018 11:34:06 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 11:34:06 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <5692d3b6-038e-4c4b-c5b6-b0f719b4ac38@digitaldaemon.com> References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> <5692d3b6-038e-4c4b-c5b6-b0f719b4ac38@digitaldaemon.com> From: Warner Losh Date: Sun, 29 Apr 2018 12:34:06 -0600 X-Google-Sender-Auth: 2OHb_nsgMQX9zCbsizBr0zA17fE Message-ID: Subject: Re: Getting ZFS pools back. To: Jan Knepper Cc: Willem Jan Withagen , Alan Somers , FreeBSD Filesystems , FreeBSD Hackers , Richard Yao Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 18:34:08 -0000 On Sun, Apr 29, 2018 at 12:31 PM, Jan Knepper wrote: > However, most 11.x binaries work well enough to at least bootstrap / fix > problems if booted on a 10.x kernel due to targeted forward compatibility. > You shouldn't count on it for long, but it generally won't totally brick > your box. In the past, and I believe this is still true, they work well > enough to compile and install a new kernel after pulling sources. The 10.x > -> 11.x syscall changes are such that you should be fine. At least if you > are on UFS. > > However, the ZFS ioctls and such are in the bag of 'don't specifically > guarantee and also they change a lot' so that may be why you can't mount > ZFS by UUID. I've not checked to see if there's specifically an issue here > or not. The ZFS ABI is somewhat more fragile than other parts of the > system, so you may have issues here. > > If all else fails, you may be able to PXE boot an 11 kernel, or boot off a > USB memstick image to install a kernel. > > Generally, while we don't guarantee forward compatibility (running newer > binaries on older kernels), we've generally built enough forward compat so > that things work well enough to complete the upgrade. That's why you > haven't hit an issue in 18 years of upgrading. However, the velocity of > syscall additions has increased, and we've gone from fairly stable (stale?) > ABIs for UFS to a more dynamic one for ZFS where backwards compat is a bit > of a crap shoot and forward compat isn't really there at all. That's likely > why you've hit a speed bump here. > > I have not closely looked at the procedures outlined in /usr/src/UPDATING > for 11.x. But do I read correctly that performing a buildworld, > buildkernel, then installworld and reboot to update from 10.4 to 11.x does > not work? > No. That will work. If you always install a new kernel and reboot (especially across major releases) and then install the new binaries, you're safe. You won't get into a situation where new binaries are running on an old kernel. As far as I know that's not broken, even with the strange ABI issues I talk about. That's only when you're running 11.x binaries on a 10.x kernel, not the other way around. Warner From owner-freebsd-hackers@freebsd.org Sun Apr 29 18:37:26 2018 Return-Path: Delivered-To: freebsd-hackers@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 171E4FB4A55 for ; Sun, 29 Apr 2018 18:37:26 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id A917B71976 for ; Sun, 29 Apr 2018 18:37:25 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: (qmail 29312 invoked by uid 89); 29 Apr 2018 18:37:21 -0000 Received: from c-24-0-179-87.hsd1.nj.comcast.net (HELO iMac.local) (jan@digitaldaemon.com@24.0.179.87) by digitaldaemon.com with SMTP; 29 Apr 2018 18:37:21 -0000 Subject: Re: Getting ZFS pools back. To: Willem Jan Withagen , Alan Somers Cc: FreeBSD Filesystems , FreeBSD Hackers , Richard Yao References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> <31f9e4cd-4865-651a-0966-4600101beb8f@digiware.nl> From: Jan Knepper Message-ID: Date: Sun, 29 Apr 2018 14:37:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <31f9e4cd-4865-651a-0966-4600101beb8f@digiware.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 18:37:26 -0000 On 04/29/2018 14:32, Willem Jan Withagen wrote: > On 29/04/2018 19:57, Jan Knepper wrote: >> On 04/29/2018 13:27, Willem Jan Withagen wrote: >>> Trouble started when I installed (freebsd-update) 11.1 over a >>> running 10.4. Which is sort of scarry? >> This does sounds 'scary' as I am planning to do this in the (near) >> future... >> >> Has anyone else experienced issues like this? >> >> Generally I do build the new system software on a running system, but >> then go to single user mode to perform the actual install. >> >> I have done many upgrades like that over 18 or so years and never >> seen or heard of an issue alike this. > > Most of my upgrades went smooth, other than being pestered by files > that are only changed in verssion no and/or comments. Yeah... Know about those... mergemaster has a option to elevate some of that pain though... > This is a rather old server that I installed zfs-on-root, when there > were only howtos and no automagic installers. So I guess that it might > even be from the 9.x days. It went through several manual upgrades and > at least once a online disk replacement with growing disks (500G to 4T). > Al that went well, but could very well be that some odd bits and pieces > were (missing) left overs. OK... That might explain a thing or two... I do recall installing 9.x I think on a new server (hardware) and having to do the ZFS setup manually... Everything currently runs 10.x > So Don't excluded that there is pilot error involved. > I tried Google to find more about fixing the system when this error > got reported, but only a rather hefty session with Andriy Gapon, I think. > And that was for 9.x or so. > Nothing else... > > So given my need to go on, I just reinstalled. OK! Thank you for letting me know! ManiaC++ Jan Knepper From owner-freebsd-hackers@freebsd.org Sun Apr 29 19:36:33 2018 Return-Path: Delivered-To: freebsd-hackers@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 56394FB66C5; Sun, 29 Apr 2018 19:36:33 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C63427ED82; Sun, 29 Apr 2018 19:36:32 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.alameda.xse.com; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.alameda.xse.com (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w3TJa6AS052823 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 29 Apr 2018 12:36:08 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.alameda.xse.com Subject: Re: Getting ZFS pools back. To: Warner Losh , Jan Knepper References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> <5692d3b6-038e-4c4b-c5b6-b0f719b4ac38@digitaldaemon.com> Cc: FreeBSD Filesystems , FreeBSD Hackers , Richard Yao , Willem Jan Withagen , Alan Somers From: Craig Leres Message-ID: Date: Sun, 29 Apr 2018 12:36:05 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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-Virus-Scanned: clamav-milter 0.100.0 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-4746-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 19:36:33 -0000 On 04/29/18 11:34, Warner Losh wrote: > If you always install a new kernel and reboot > (especially across major releases) and then install the new binaries, > you're safe. I upgraded 40+ systems from 10.3-RELEASE to 11.1-RELEASE over the last few weeks including 8 or so with zfs partitions (but all boot off of ufs2). The work flow I converged on was: - (I use rcs for configs so) co -l all customized config files - Check /etc/freebsd-update.conf for the desired config - Download the upgrade updates (freebsd-update upgrade -r 11.1-RELEASE) - Check /etc/rc.conf and disable kern_securelevel if enabled - Check/update /etc/resolv.conf if using bind9* - Switch to /usr/bin/sshd if using openssh-portable - Copy and install custom 11.1 kernel from my build server - Stop most services - Save a list of installed packages: pkg info|sed -e 's/-[0-9a-zA-Z._,]* *.*//' > /var/tmp/a - Remove all packages (pkg-static delete -fya) - Reboot - Run "freebsd-update install" three times - Reinstall packages: pkg update -f pkg clean -ay pkg install -y `cat /var/tmp/a` - Check/reset/checkin configs and reboot I had zero^H^H^H^Hno zfs issues. On 04/29/18 11:32, Willem Jan Withagen wrote: > Most of my upgrades went smooth, other than being pestered by > files that are only changed in verssion no and/or comments. I also find this annoying but started manually updating things that were problematic before starting which minimized freebsd-update merging. Craig From owner-freebsd-hackers@freebsd.org Sun Apr 29 21:20:05 2018 Return-Path: Delivered-To: freebsd-hackers@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 392DDFB953A; Sun, 29 Apr 2018 21:20:05 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 C127276035; Sun, 29 Apr 2018 21:20:04 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 57BA43DD27; Sun, 29 Apr 2018 23:20:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pns3VvmlAITH; Sun, 29 Apr 2018 23:20:01 +0200 (CEST) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 462423DD26; Sun, 29 Apr 2018 23:20:01 +0200 (CEST) Subject: Re: Getting ZFS pools back. To: Warner Losh , Jan Knepper Cc: Alan Somers , FreeBSD Filesystems , FreeBSD Hackers , Richard Yao References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> From: Willem Jan Withagen Message-ID: <7588abf8-16e4-8820-a0e5-e019a02a7bd6@digiware.nl> Date: Sun, 29 Apr 2018 23:20:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 21:20:05 -0000 On 29/04/2018 20:21, Warner Losh wrote: > > > On Sun, Apr 29, 2018 at 11:57 AM, Jan Knepper > wrote: > > On 04/29/2018 13:27, Willem Jan Withagen wrote: > > Trouble started when I installed (freebsd-update) 11.1 over a > running 10.4. Which is sort of scarry? > > This does sounds 'scary' as I am planning to do this in the (near) > future... > > Has anyone else experienced issues like this? > > Generally I do build the new system software on a running system, > but then go to single user mode to perform the actual install. > > I have done many upgrades like that over 18 or so years and never > seen or heard of an issue alike this. > > > 11.x binaries aren't guaranteed to work with a 10.x kernel. So that's a > bit of a problem. freebsd-update shouldn't have let you do that either. > > However, most 11.x binaries work well enough to at least bootstrap / fix > problems if booted on a 10.x kernel due to targeted forward > compatibility. You shouldn't count on it for long, but it generally > won't totally brick your box. In the past, and I believe this is still > true, they work well enough to compile and install a new kernel after > pulling sources. The 10.x -> 11.x syscall changes are such that you > should be fine. At least if you are on UFS. I have been doing those kind of this for years and years. Even upgrading over NFS and stuff. Sometimes it is a bit too close to the sun and things burn. But never crash this bad. > However, the ZFS ioctls and such are in the bag of 'don't specifically > guarantee and also they change a lot' so that may be why you can't mount > ZFS by UUID. I've not checked to see if there's specifically an issue > here or not. The ZFS ABI is somewhat more fragile than other parts of > the system, so you may have issues here. > > If all else fails, you may be able to PXE boot an 11 kernel, or boot off > a USB memstick image to install a kernel. Tried just about replace everything in both the boot-partition (First growing it to take > 64K gptzfsboot) and in /boot from the memstick. But the error never went away. Never had ZFS die on me this bad, that I could not get it back. > Generally, while we don't guarantee forward compatibility (running newer > binaries on older kernels), we've generally built enough forward compat > so that things work well enough to complete the upgrade. That's why you > haven't hit an issue in 18 years of upgrading. However, the velocity of > syscall additions has increased, and we've gone from fairly stable > (stale?) ABIs for UFS to a more dynamic one for ZFS where backwards > compat is a bit of a crap shoot and forward compat isn't really there at > all. That's likely why you've hit a speed bump here. Come to think of it, I did not do this step with freebsd-update, since I was not at an official release yet. I was going to 11.1-RELEASE, to be able to start using freebsd-update. So I don't think I did just do that.... But I tried so much yesterday. Normally I would installkernel, reboot, installworld, mergemaster, reboot for systems that are not up for freebsd-update. --WjW From owner-freebsd-hackers@freebsd.org Sun Apr 29 22:02:28 2018 Return-Path: Delivered-To: freebsd-hackers@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 15EBDFBAD1F for ; Sun, 29 Apr 2018 22:02:28 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7763280086 for ; Sun, 29 Apr 2018 22:02:27 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-lf0-x22f.google.com with SMTP id h197-v6so9738848lfg.11 for ; Sun, 29 Apr 2018 15:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+1K4UXymn2UAVr0xUTDlpEm3F0JOovEPjFhVqPtiAm4=; b=SLLin1nsuVJwW/gqWAPZXT3JTgPdYTT047Pwyr55aNvfbWPNWUs3MDzxJObkvexXJF wpPtTFT0KdmBzrfOqFOOScOUg5tCfnoUKMtEwinon4wwAQw75Rzb47A9Rpu3KPEVTpxs SPHMZPHA+SgCJ8uMDZos59WyPF6k2y4xa57tchaKdkf6JFKoVSDkpRG4m+IcXR4NXEhp WwtSScbsDYpcoNelmThCiWXqAzZSKgfCl64waeAEDpBpvji0JY7c4aj+9SFBUhlgZ/YT dHFfDof8N+DwSBsm1UpxGB1dmon80eIPmtHBjUxwZx+KjXxJSeei1S270ahnqZvHJ5ey zd5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+1K4UXymn2UAVr0xUTDlpEm3F0JOovEPjFhVqPtiAm4=; b=WSlEp3qEx+x327cItdHs9cHtP8Va/Rw7YEMMEsieKjOXGaHa3WQqZz/eBQCk46XwL4 B5NzDw45l5GEGYKWUbeFeMvjfvk5GMCxXY2+blbPlfDl6VVOMh4vhqGkOyrC/klPUxcO 2LUMh6LkwIQzf1CJnxd4tlac7tfwffDipQubgIWR2NRu8kamRXJ9lbiDDyTRjQ3GIPGE 7Zy3dT01gmiGD76ycUgqg0sil9q5TbVsGlX42NJ8sIJZj99Bhj8lLAO0B5GPTpn7a72T NhtnZ/aI7gV9YnS+4MneN+vdxPrupbt1RuVJ0iSuaOtopNF2PAIKlQeTLoQPz2a4gqjZ 5UXw== X-Gm-Message-State: ALQs6tDupYbBRISbZgc+prSOHVAC/mdxS+h5+peJDij7E93FSsElvlE1 ORqmex5+F2ZKtofend2Ne5TFtiUf2ERK8O1p03BTWDdM X-Google-Smtp-Source: AB8JxZovy+RcMy4GFyf/XnJ+N+rU22H1U8ue8Zsjqd8sFfhTmXuCvEDTyQlVBvEtg9ZcRsKskDn3zvd863oY3I7QsY0= X-Received: by 2002:a19:5a1d:: with SMTP id o29-v6mr5738411lfb.93.1525039344981; Sun, 29 Apr 2018 15:02:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:294d:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 15:01:54 -0700 (PDT) In-Reply-To: References: From: Ed Schouten Date: Mon, 30 Apr 2018 00:01:54 +0200 Message-ID: Subject: Re: "Sysctl as a Service" for influxdb / telegraf To: Eitan Adler Cc: FreeBSD Hackers , daniel.nelson@influxdb.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 22:02:28 -0000 Hi Eitan, 2018-04-29 7:24 GMT+02:00 Eitan Adler : > I've been talking with the maintainer of telegraf about implementing > an importer for the Prometheus exporter. They mentioned that they'd > prefer a slightly different format. I'd like to add a new independent > application similar to prometheus_sysctl_exporter for the influx wire > format. I just browsed through the Telegraf GitHub page and noticed that Telegraf even has integrated support for parsing metrics in Prometheus' format: https://github.com/influxdata/telegraf/tree/master/plugins/inputs/prometheus Considering this and the ongoing standardisation effort, maybe it makes more sense to stick to a single exporter? We can consider extending the man page to mention that it can also be used in combination with Telegraf. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands From owner-freebsd-hackers@freebsd.org Mon Apr 30 05:11:18 2018 Return-Path: Delivered-To: freebsd-hackers@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 E643AFC3592 for ; Mon, 30 Apr 2018 05:11:17 +0000 (UTC) (envelope-from lakhanshiva@gmail.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 760CE7C9CC for ; Mon, 30 Apr 2018 05:11:17 +0000 (UTC) (envelope-from lakhanshiva@gmail.com) Received: by mail-ot0-x22b.google.com with SMTP id i5-v6so8264513oth.1 for ; Sun, 29 Apr 2018 22:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zpeIX2JwTTFneYrpy0LIjiEa9JEeKq1tkE6rY+t9g20=; b=dcgRJ/mEvsBCeYEWbAhP8gvelLfNtpE8fRsXB1AJWIIakrFtWSrNEUkHL5DeUwCoI+ c+c8frSaDssX3UEb6ejN6k3JRoF/+6Pomg5zj1jSTGdKknZB9C6w8wzklRLjmlHLq32G tiiBG6+w8vT/WCjcmIB2m64TPoN+Do3zABvpRlWq2aCocM3sAMNr5CUHVC8NwqTyC78b 1lPfJoz22FFiVdMfDBAJfuUmsBJy93D98qQvC28cbktkBDx60P1Zy518VoJ9LfA/W7Xb 7TgnZDqGkmhrEAj9pn2swWZqx1NOwRPu06kQ6U/C4QgfnhF9ZaZ1y3SGyPR3US5lOJNI tnqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zpeIX2JwTTFneYrpy0LIjiEa9JEeKq1tkE6rY+t9g20=; b=g8EfIyAvNwahVP9DPSvi25FKTE7IGvRRjwd5oJDzKlDdU9f9m7svVmvxoOZxLe2lhm gdUaoCisdp1Zt5YJpYY690dwzT9nC0UvBClUoR6Wg2LeoH7a4EupPVLVGgkrENG4u9S2 2X4xBIuP1ygqujyKbnRS4ejvwtXJ4SXca/615PhSih5GFZSOS1XGYk1O6eJzZ2YNwClh xYSfT5hKAx8cr0sLLSF58rmVSA9bKVCyEYdz/x7Bh9cwgrsj5GWhTFZExFoPwsimhz58 o7NaqMrhiswJN1dJw8oyIFDsX5ticK5lC2LOw2uUuQ9XSakI1xezhczYxxfzSe9m2Mel 7cMg== X-Gm-Message-State: ALQs6tCnxUm82wy8n3Q+bu4xDsh26F9hxUHuR1LjXXoqnWoXq2mra8rK itfD3xYMij/UGJJ3uwollmjPSRyooeQAj4a6NG0= X-Google-Smtp-Source: AB8JxZqYlyzu4MfW7Tynd3jmvH3H8O14DQt+Ua89IDiRkYEO5l7a8F2fEg99dAFho7tPS8ozfaE8EbWi4urF64DTogE= X-Received: by 2002:a9d:5a17:: with SMTP id v23-v6mr4493356oth.387.1525065076482; Sun, 29 Apr 2018 22:11:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:44ad:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 22:11:15 -0700 (PDT) From: Lakhan Shiva Date: Mon, 30 Apr 2018 10:41:15 +0530 Message-ID: Subject: Convert PCI drivers to be table driven To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 05:11:18 -0000 Hi All, My name is Lakhan Kamireddy. I have been accepted to GSoC for the project to Convert PCI drivers attachments to be table driven. We currently have a devmatch infrastructure that gives us a way to match up hardware with kernel modules. But, for devmatch to use them, they need to have their device ID scans done via a table. The table needs to be decorated with PNP_INFO tag. Here we also need to automate testing of this drivers to make sure they work somehow. You can find my document below - From owner-freebsd-hackers@freebsd.org Mon Apr 30 05:12:21 2018 Return-Path: Delivered-To: freebsd-hackers@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 44173FC377A for ; Mon, 30 Apr 2018 05:12:21 +0000 (UTC) (envelope-from lakhanshiva@gmail.com) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEEE57CCE0 for ; Mon, 30 Apr 2018 05:12:20 +0000 (UTC) (envelope-from lakhanshiva@gmail.com) Received: by mail-ot0-x241.google.com with SMTP id w4-v6so8245714ote.12 for ; Sun, 29 Apr 2018 22:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XkzDXOwLbmkIBNltqJg6OowjyVmQ9v5ZS9SgjIbvyUY=; b=SLwxisXjTuMQibAN0u84Mt+JJc2Q8ujrILqNl1Ag5TqwNmlJSbeKZKMIJUNGkqwvKh F7xThSIknXpzUJmdqrAFuOGfsHL7MyMoJB0qiD+ke8qJTW5i3pc1cXfma3Plf4B4FpZR 6cKRzBMIHnYuVqNWbVH3WTf+9s9M15rWgTgqDFfbB2KLsn03tseUtk2yoegT8qMxxffS aairP4knUSWzOFVP2PSTJKuHy8fhvTu2w80vi514VPvuvqIFjA/mDADfldgVB0TXCt3v qoW5HwCywWNjBCh2U9MoRGXMjpuGT4Ocg6NiE4tXU1BWAayfXKjfWssArsxgw6S6VJ5L tuVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XkzDXOwLbmkIBNltqJg6OowjyVmQ9v5ZS9SgjIbvyUY=; b=YzIZJhM9EyJw7BMNfgsXCOp7avrpr60j4dsjR6WKdfgZz1lqITOJr74T131kG/84tf 9OdmiGQtJZ2hbxOzo4hJJfMsAMA7RAJR99HdIt5knvrVM7zgv+fsgugcLDdPTCWEdGku sEWyHkdVub5R3fDwwSzS17ck3h7z7mw8s92z+VVjiQW1zPHPDEdKDf1ViTEILLN0rzdO J36K0aABmiC6JRB4RbqQO664S9U3qleA7UNy9R1VM+5qpvCF33GxVY8pSe8r+g0jpXl6 IpvRWGouoNc9KAPlm341QRWa1FsAIIhy+O1nTvIuZ5TM5O8f8msxRJpbuYp94O3sIEZ7 quUQ== X-Gm-Message-State: ALQs6tAKN0G0ykIcPPr9otU+URSG9IiAmMLx/Akkbj9M6bx8UAh3wSvC Y8LEalBeu/qZFFSVparTe9wAzPorlruAf8/5EZCZjw== X-Google-Smtp-Source: AB8JxZp3ur0AM8zjOiDuu1ZHO5Rq0gx9f3KXabdLQMOgU2LNkS7rGH3d/SrnRGSkh3OAgaqF7FZKokYwK3DHuq0TjO4= X-Received: by 2002:a9d:34fc:: with SMTP id t57-v6mr7880594otd.342.1525065139953; Sun, 29 Apr 2018 22:12:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:44ad:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 22:12:19 -0700 (PDT) In-Reply-To: References: From: Lakhan Shiva Date: Mon, 30 Apr 2018 10:42:19 +0530 Message-ID: Subject: Re: Convert PCI drivers to be table driven To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 05:12:21 -0000 https://docs.google.com/document/d/1bB_2Hgadg-3CEgashcM85-MzIOqRXT9wIEEfAstbPlU/edit?usp=sharing I would like to know if you have any feedback regarding this project - any helpful reviews or ideas. Thanks, Lakhan Kamireddy On Mon, Apr 30, 2018 at 10:41 AM, Lakhan Shiva wrote: > Hi All, > > My name is Lakhan Kamireddy. I have been accepted to GSoC for the project > to Convert PCI drivers attachments to be table driven. We currently have a > devmatch infrastructure that gives us a way to match up hardware with > kernel modules. But, for devmatch to use them, they need to have their > device ID scans done via a table. The table needs to be decorated with > PNP_INFO tag. > Here we also need to automate testing of this drivers to make sure they > work somehow. > > You can find my document below - > From owner-freebsd-hackers@freebsd.org Mon Apr 30 10:37:51 2018 Return-Path: Delivered-To: freebsd-hackers@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 8D286FCACBE; Mon, 30 Apr 2018 10:37:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (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 2611D78C10; Mon, 30 Apr 2018 10:37:50 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id AF4C23D4F4; Mon, 30 Apr 2018 12:37:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovyt5Zq6dPbv; Mon, 30 Apr 2018 12:37:47 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 5604E3D4F0; Mon, 30 Apr 2018 12:37:47 +0200 (CEST) Subject: Re: Getting ZFS pools back. From: Willem Jan Withagen To: Warner Losh , Jan Knepper Cc: FreeBSD Filesystems , FreeBSD Hackers , Richard Yao , Alan Somers References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> <7588abf8-16e4-8820-a0e5-e019a02a7bd6@digiware.nl> Message-ID: Date: Mon, 30 Apr 2018 12:37:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7588abf8-16e4-8820-a0e5-e019a02a7bd6@digiware.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 10:37:51 -0000 On 29-4-2018 23:20, Willem Jan Withagen wrote: > On 29/04/2018 20:21, Warner Losh wrote: >> >> >> On Sun, Apr 29, 2018 at 11:57 AM, Jan Knepper > > wrote: >> >>     On 04/29/2018 13:27, Willem Jan Withagen wrote: >> >>         Trouble started when I installed (freebsd-update) 11.1 over a >>         running 10.4. Which is sort of scarry? >> >>     This does sounds 'scary' as I am planning to do this in the (near) >>     future... >> >>     Has anyone else experienced issues like this? >> >>     Generally I do build the new system software on a running system, >>     but then go to single user mode to perform the actual install. >> >>     I have done many upgrades like that over 18 or so years and never >>     seen or heard of an issue alike this. >> >> >> 11.x binaries aren't guaranteed to work with a 10.x kernel. So that's >> a bit of a problem. freebsd-update shouldn't have let you do that either. >> >> However, most 11.x binaries work well enough to at least bootstrap / >> fix problems if booted on a 10.x kernel due to targeted forward >> compatibility. You shouldn't count on it for long, but it generally >> won't totally brick your box. In the past, and I believe this is still >> true, they work well enough to compile and install a new kernel after >> pulling sources. The 10.x -> 11.x syscall changes are such that you >> should be fine. At least if you are on UFS. > > I have been doing those kind of this for years and years. Even upgrading > over NFS and stuff. Sometimes it is a bit too close to the sun and > things burn. But never crash this bad. > >> However, the ZFS ioctls and such are in the bag of 'don't specifically >> guarantee and also they change a lot' so that may be why you can't >> mount ZFS by UUID. I've not checked to see if there's specifically an >> issue here or not. The ZFS ABI is somewhat more fragile than other >> parts of the system, so you may have issues here. >> >> If all else fails, you may be able to PXE boot an 11 kernel, or boot >> off a USB memstick image to install a kernel. > > Tried just about replace everything in both the boot-partition (First > growing it to take > 64K gptzfsboot) and in /boot from the memstick. > But the error never went away. > > Never had ZFS die on me this bad, that I could not get it back. > >> Generally, while we don't guarantee forward compatibility (running >> newer binaries on older kernels), we've generally built enough forward >> compat so that things work well enough to complete the upgrade. That's >> why you haven't hit an issue in 18 years of upgrading. However, the >> velocity of syscall additions has increased, and we've gone from >> fairly stable (stale?) ABIs for UFS to a more dynamic one for ZFS >> where backwards compat is a bit of a crap shoot and forward compat >> isn't really there at all. That's likely why you've hit a speed bump >> here. > > Come to think of it, I did not do this step with freebsd-update, since I > was not at an official release yet. I was going to 11.1-RELEASE, to be > able to start using freebsd-update. > > So I don't think I did just do that.... But I tried so much yesterday. > Normally I would installkernel, reboot, installworld, mergemaster, > reboot for systems that are not up for freebsd-update. Right, The story gets even sadder ..... Took the "spare" disk home, and just connected it to an older SuperMicro server I had lying about for Ceph tests. And lo and behold, it just boots. So that system got upgraded from: 10.2 -> 10.4 -> 11.1 No complaints about anything. So now I'm inclined to point at older hardware with an old bios, which confused ZFS, or probably more precisely gptzfsboot. From dmidecode: System Information Manufacturer: Supermicro Product Name: H8SGL Version: 1234567890 BIOS Information Vendor: American Megatrends Inc. Version: 3.5 Release Date: 11/25/2013 Address: 0xF0000 We only have 1 of those, so further investigation, and or tinkering, in combo with the hardware will be impossible. --WjW From owner-freebsd-hackers@freebsd.org Mon Apr 30 10:44:22 2018 Return-Path: Delivered-To: freebsd-hackers@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 71ABCFA4025 for ; Mon, 30 Apr 2018 10:44:22 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id DBD5A7A532 for ; Mon, 30 Apr 2018 10:44:21 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman-wireless.lon.namesco.net (lon.namesco.net [195.7.254.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by unsane.co.uk (Postfix) with ESMTPSA id 9830E30012 for ; Mon, 30 Apr 2018 11:44:15 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=unsane.co.uk; s=251017; t=1525085055; bh=lEneaJWFSv1ezAsUCeuBdVpRZvFNhBt7EoNBq5serYo=; h=Subject:To:References:From:Date:In-Reply-To; b=DwZ8E3TArgXJJfRRp8TGFVROLwsgV6KLoV+8DG1GdJYDun+h0tdh6Ni+TKopOcDu0 7fW/IebNuwAumVjDB7VJTgLw5CbhYtJ8zOkVog/QzaQrNygpQlQy6BF9wAiXQQQXde RM9nImitAYPJ2dpCq/T7I8NcmEp1nxaqvaAyUYYE= Subject: Re: Can we please finally solve Dell's racadm for FreeBSD? Advice needed To: freebsd-hackers@freebsd.org References: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> From: Vincent Hoffman-Kazlauskas Openpgp: preference=signencrypt Autocrypt: addr=vince@unsane.co.uk; prefer-encrypt=mutual; keydata= xsDiBESPz78RBADybNTkAA4eQLuwYC1Qsn7qaDLzBvq2RmA0niwngigEPy/tLh9aF2zR85fL PTvxh9MyLzFZHc5RVO0tKM93CSRXjTo5xo2P1/YTopPyzTBB3eOB7uqJRi+suBnKPfXvkeW1 g5yo3pKINsqW0ed91lDwrQ1NofbIFkOOYnhQpccdiwCg0GF13Vk9Rz683bkSawFethAcVx8E AKGPTj6KfVmnhB8a3y0UeZ46LMfoZnjLF4ZDMtrZHY639zbZBJiKJ/M1B8z3GJgmRmOEXoW4 Mdoi0XaSkinIWmtdI+vhIfb/7ufFzujM0wEbEnpJ/mvTuSas6DG7MPMiJMavz3Hf/dVOX7Dd Ma+z03JKIHuMj8HVMFccjgFJLmteBADkdDBQin+YzgGuPs/Sf8KvVPVRDT5QJkHUEU/gcmSP YbPfmwC7tl1iXR9Gu4foQyk2UJJezCRUWggNScybcrLp2jQ0XWkw18uus/QC2ZCfW/f2vXg8 uL5W7cLGbeSKh3K0CFMbACmcrcMZk7JwW9a/VlAhmqOUk1MYJ1rR2ZZIp80mVmluY2VudCBI b2ZmbWFuIDx2aG9mZm1hbkBuYW1lcy5jby51az7CYAQTEQIAIAUCRI/PvwIbAwYLCQgHAwIE FQIIAwQWAgMBAh4BAheAAAoJEMQkmEPMfxC+ik0An0EFsHC1cTRRq+MgAWoM3WRvOeQFAJ9D 2GwjK6Zaiu6s+KaxeWh4yrk0Jc7BTQREj8/REAgA5AQP4RpCo/O9U/Zd4s0mArJpGQhAnYb8 2r+u3e/MyGK5hTH+ODAOZ1TeiPb75xYQ9QGOX+ygpCSDmDjG+MJyPivdZMuuwnhisYZPNuhE Tw/CdP5mekqPzZAvIqBi5q6Bdmz0tORu4L6y/zPnQ8qrkBnibK9AOKz1XkguOlzcIlfxpsOC AgTRWoOpW8oQtQl80Ik22prSExgKllBfq3/sRix28r86L51P5hHG7mlWtbv8txaLyihBO3aw mkTXLAk5IMgrlillkDvMYUsO7lOkwk54C3oq+lYarNJ4Ul7Wfyg1ufjCc8CynXrlgFMJ+wbg Uhk4lbidSuGRkT10yqlNrwAECwf/YA3W3eSNQIn6s5eBTR+Qocmp+11zTNQMwB3xRzKQFBBd UwTbFiyhxMS7+xJzEUzuhTOy/OI/QCto595C/68y53TU0fwII0e2XLRYDIWO1FqSCGyDMviO 1ixnSHMkXeIEPbalF9n+KB2ozX0OOxl3oA7wt/DmOq8nLNzCMOKHD6mJRnBAp0En9WYpnbSl nucjh2+Ry9XAK5HCZ9k1SWxFPCEvxv4nwhZnYFdm5O4M6MHw8T/viWIBa96yt2CTGP7gOz+s YKcjUTQ7UdtYFVguGW9uehvtqbCLv69clBCmooRYAmTkiupI8R1zIfKVDjllDONWoPZfCz2d LwHnLW/ZMsJJBBgRAgAJBQJEj8/RAhsMAAoJEMQkmEPMfxC+he0An3g4+nwMH9lsde9IFgQY TDhDySz9AKCZSsEaPlGPvj7Fd7c47Eh4Nt9j9w== Message-ID: Date: Mon, 30 Apr 2018 11:44:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 10:44:22 -0000 for a quick tl;dr kldload ipmi pkg install freeipmi ipmitool dmidecode --string system-product-name PowerEdge R420 [root@brittlestar ~]# ipmi-sensors | head -4 ID | Name | Type | Reading | Units | Event 1 | SEL | Event Logging Disabled | N/A | N/A | N/A 2 | Intrusion | Physical Security | N/A | N/A | 'OK' 11 | Fan1A | Fan | 6240.00 | RPM | 'OK' or for an r210 root@helios:~ # ipmi-sensors | grep -i intr 31 | Intrusion | Physical Security | N/A | N/A | 'OK' see also the rest of the freeipmi utils and maybe ipmitool for a different interface (I prefer it for some uses) Vince On 29/04/2018 15:28, Peter G. wrote: > On 29/04/2018 05:08, Jack L. wrote: >> I manage a variety of Dell servers running FreeBSD, only 610 and 1950s >> work with racadm but everything that can be done with racadm can also >> be done with ipmitool. I just use ipmitool to get around instead of >> their proprietary racadm stuff. What functionality do you need from >> racadm and maybe I can give you an ipmitool equivalent? > > It seems I may missed the ipmi angle altogether assuming it was only > remote. Only now following Dan's comments I am realizing how racadm > works talking to local hardware. > > You mean using this impi(4) as a local device and talking to it via > local tool allowing coms with the device? Oh, that would do nicely. I > need this for scripting mostly, e.g. monitoring what the intrusion > sensor shows. > > Can you please describe your setup? What other kernel modules and 3rd > party software do you employ? Any tricks with device.hints are needed? I > have a small R220 at hand for testing, but it's lacking impi(4) > altogether. Will have to rebuild. > > -- > PG > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Apr 30 11:16:52 2018 Return-Path: Delivered-To: freebsd-hackers@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 F163CFA4F0C for ; Mon, 30 Apr 2018 11:16:51 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 839FF80E7E for ; Mon, 30 Apr 2018 11:16:51 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1fD6nY-000073-Sp for freebsd-hackers@freebsd.org; Mon, 30 Apr 2018 13:16:48 +0200 Received: from [::1] (port=38164 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1fD6nY-00025B-OM for freebsd-hackers@freebsd.org; Mon, 30 Apr 2018 13:16:48 +0200 Received: from mx10.freenet.de ([195.4.92.20]:59100) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1fD6lQ-0006ym-24 for freebsd-hackers@freebsd.org; Mon, 30 Apr 2018 13:14:36 +0200 Received: from p5b22a51e.dip0.t-ipconnect.de ([91.34.165.30]:51393 helo=freebsd-t450.fritz.box) by mx10.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (port 587) (Exim 4.90_1 #2) id 1fD6lP-0000Z4-Uk for freebsd-hackers@freebsd.org; Mon, 30 Apr 2018 13:14:36 +0200 Date: Mon, 30 Apr 2018 13:14:34 +0200 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-hackers@freebsd.org Subject: Getting pthread names Message-ID: <20180430111434.GA18085@freebsd-t450.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.9.5 (2018-04-13) X-Spamscore: -0.1 (/) X-Spamreport: Action: no action Symbol: RCVD_VIA_SMTP_AUTH(0.00) Symbol: RCPT_COUNT_ONE(0.00) Symbol: NEURAL_SPAM(0.00) Symbol: TO_DN_NONE(0.00) Symbol: RCVD_COUNT_ONE(0.00) Symbol: ASN(0.00) Symbol: FROM_HAS_DN(0.00) Symbol: MIME_GOOD(-0.10) Symbol: BAYES_HAM(-0.00) Symbol: RCVD_TLS_ALL(0.00) Symbol: FROM_EQ_ENVFROM(0.00) Symbol: TO_MATCH_ENVRCPT_ALL(0.00) Message-ID: 20180430111434.GA18085@freebsd-t450.fritz.box X-FN-Spambar: X-Originated-At: 91.34.165.30!51393 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 11:16:52 -0000 Hi, for setting a name for pthreads i found pthread_set_name_np(3), but for retrieving the name i found nothing. Is there any api like pthread_getname_np for FreeBSD? Or is there another way to retrieve the threads name within an application? From owner-freebsd-hackers@freebsd.org Mon Apr 30 12:22:58 2018 Return-Path: Delivered-To: freebsd-hackers@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 B99B7FA8B37 for ; Mon, 30 Apr 2018 12:22:58 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D9396EAFE for ; Mon, 30 Apr 2018 12:22:57 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w3UBwjWq019532 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 30 Apr 2018 13:58:45 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w3UBwe0s019529 for ; Mon, 30 Apr 2018 13:58:40 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Mon, 30 Apr 2018 13:58:40 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: new laptop, no sound in spite of driver attaching Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 12:22:58 -0000 and no idea where to search for a solution FreeBSD laptop.wojtek.intra 11.1-STABLE FreeBSD 11.1-STABLE #2: Mon Apr 30 13:35:54 CEST 2018 root@laptop.wojtek.intra:/usr/src/sys/amd64/compile/laptop amd64 in dmesg hdac0: mem 0x91410000-0x91413fff irq 22 at device 27.0 on pci0 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20 and 25 on hdaa0 pcm1: at nid 33 and 18 on hdaa0 hdacc1: at cad 2 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 5 on hdaa1 tried to change hw.snd.default_unit to 0, 1 or 2 - no sound in any case. mixer when default_unit is 0 Mixer vol is currently set to 65:65 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 100:100 Mixer mic is currently set to 0:0 Mixer mix is currently set to 100:100 Mixer rec is currently set to 0:0 Mixer igain is currently set to 0:0 Mixer ogain is currently set to 100:100 Recording source: mic mixer when default_unit is 1 Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 Mixer rec is currently set to 37:37 Mixer igain is currently set to 0:0 Mixer monitor is currently set to 56:56 mixer when default_unit is 2 Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 this is HP 250 G5 laptop please help From owner-freebsd-hackers@freebsd.org Mon Apr 30 13:25:22 2018 Return-Path: Delivered-To: freebsd-hackers@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 D4999FAB291 for ; Mon, 30 Apr 2018 13:25:22 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A3727D637 for ; Mon, 30 Apr 2018 13:25:22 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [IPv6:2600:1:f45e:b478:dd3a:c418:c4d8:a451] (unknown [IPv6:2600:1:f45e:b478:dd3a:c418:c4d8:a451]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id D7B7D335C99; Mon, 30 Apr 2018 13:25:20 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Getting pthread names From: Richard Yao X-Mailer: iPhone Mail (15E302) In-Reply-To: <20180430111434.GA18085@freebsd-t450.fritz.box> Date: Mon, 30 Apr 2018 09:25:14 -0400 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <37C69B52-808C-4F9A-B00A-679564F4BCE0@gentoo.org> References: <20180430111434.GA18085@freebsd-t450.fritz.box> To: =?utf-8?Q?Manuel_St=C3=BChn?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 13:25:23 -0000 > On Apr 30, 2018, at 7:14 AM, Manuel St=C3=BChn w= rote: >=20 > Hi, >=20 > for setting a name for pthreads i found pthread_set_name_np(3), but for re= trieving the name i found nothing. Is there any api like pthread_getname_np f= or FreeBSD? Or is there another way to retrieve the threads name within an a= pplication? The only time that I have ever seen the names listed was when attaching gdb t= o a process on Linux and listing the threads. I have not tried it on FreeBSD= . I suggest attaching gdb to see if it displays them. If it works, then you c= ould look into how gdb gets them. I hope that helps. >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Mon Apr 30 13:57:22 2018 Return-Path: Delivered-To: freebsd-hackers@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 624CDFABF09 for ; Mon, 30 Apr 2018 13:57:22 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 D210284525 for ; Mon, 30 Apr 2018 13:57:21 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3UDvB7L098162 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Apr 2018 16:57:14 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3UDvB7L098162 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3UDvBdw098161; Mon, 30 Apr 2018 16:57:11 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Mon, 30 Apr 2018 16:57:11 +0300 From: Konstantin Belousov To: Manuel St?hn Cc: freebsd-hackers@freebsd.org Subject: Re: Getting pthread names Message-ID: <20180430135711.GT6887@kib.kiev.ua> References: <20180430111434.GA18085@freebsd-t450.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180430111434.GA18085@freebsd-t450.fritz.box> User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 13:57:22 -0000 On Mon, Apr 30, 2018 at 01:14:34PM +0200, Manuel St?hn wrote: > Hi, > > for setting a name for pthreads i found pthread_set_name_np(3), but for > retrieving the name i found nothing. Is there any api like > pthread_getname_np for FreeBSD? Or is there another way to retrieve the > threads name within an application? Not like pthread_getname_np(), but still something. You can use (binary) sysctl kern.proc.pid. to get struct kinfo_proc for all threads. In the structure, the ki_tdname() member contains the thread name as set by pthread_set_name_np(3). From owner-freebsd-hackers@freebsd.org Mon Apr 30 14:05:17 2018 Return-Path: Delivered-To: freebsd-hackers@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 658A2FAC3F7 for ; Mon, 30 Apr 2018 14:05:17 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 04799863E6; Mon, 30 Apr 2018 14:05:16 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [192.168.5.101] (pool-96-232-204-110.nycmny.fios.verizon.net [96.232.204.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id E2FC2335C60; Mon, 30 Apr 2018 14:05:15 +0000 (UTC) Mime-Version: 1.0 (1.0) Subject: Re: Getting pthread names From: Richard Yao X-Mailer: iPhone Mail (15E302) In-Reply-To: <20180430135711.GT6887@kib.kiev.ua> Date: Mon, 30 Apr 2018 10:05:13 -0400 Cc: Manuel St?hn , freebsd-hackers@freebsd.org Message-Id: <1B396EAB-CA2E-42C2-AEB0-AD89907EA6EF@gentoo.org> References: <20180430111434.GA18085@freebsd-t450.fritz.box> <20180430135711.GT6887@kib.kiev.ua> To: Konstantin Belousov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:05:17 -0000 It sounds like someone could use that to implement pthread_getname_np(3). https://www.freebsd.org/cgi/man.cgi?query=3Dsysctl&sektion=3D3&apropos=3D0&m= anpath=3DFreeBSD+11.1-RELEASE+and+Ports > On Apr 30, 2018, at 9:57 AM, Konstantin Belousov wrote: >=20 >> On Mon, Apr 30, 2018 at 01:14:34PM +0200, Manuel St?hn wrote: >> Hi, >>=20 >> for setting a name for pthreads i found pthread_set_name_np(3), but for=20= >> retrieving the name i found nothing. Is there any api like=20 >> pthread_getname_np for FreeBSD? Or is there another way to retrieve the=20= >> threads name within an application? >=20 > Not like pthread_getname_np(), but still something. You can use > (binary) sysctl kern.proc.pid. to get struct kinfo_proc for all > threads. In the structure, the ki_tdname() member contains the thread > name as set by pthread_set_name_np(3). > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Mon Apr 30 14:17:18 2018 Return-Path: Delivered-To: freebsd-hackers@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 92050FAC805 for ; Mon, 30 Apr 2018 14:17:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 237E469E74 for ; Mon, 30 Apr 2018 14:17:17 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0841fed5-4c81-11e8-bb8e-b35b57339d60 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 outbound1.ore.mailhop.org (Halon) with ESMTPSA id 0841fed5-4c81-11e8-bb8e-b35b57339d60; Mon, 30 Apr 2018 14:16:11 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w3UEH9SU035307; Mon, 30 Apr 2018 08:17:09 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1525097829.57768.140.camel@freebsd.org> Subject: Re: Getting pthread names From: Ian Lepore To: Manuel =?ISO-8859-1?Q?St=FChn?= , freebsd-hackers@freebsd.org Date: Mon, 30 Apr 2018 08:17:09 -0600 In-Reply-To: <20180430111434.GA18085@freebsd-t450.fritz.box> References: <20180430111434.GA18085@freebsd-t450.fritz.box> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:17:18 -0000 On Mon, 2018-04-30 at 13:14 +0200, Manuel Stühn wrote: > Hi, > > for setting a name for pthreads i found pthread_set_name_np(3), but > for  > retrieving the name i found nothing. Is there any api like  > pthread_getname_np for FreeBSD? Or is there another way to retrieve > the  > threads name within an application? The applications I know of that can display thread names (ps, top, procstat) retrieve it using libprocstat and the procstat_getprocs(3) function. The libprocstat functions access the information via /dev/kvm or sysctl, but those interfaces return raw binary kernel data that userland should not try to directly interpret for themselves. -- Ian From owner-freebsd-hackers@freebsd.org Mon Apr 30 14:24:46 2018 Return-Path: Delivered-To: freebsd-hackers@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 58BB5FACAC4 for ; Mon, 30 Apr 2018 14:24:46 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id D52096BBF1 for ; Mon, 30 Apr 2018 14:24:45 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: (qmail 73393 invoked by uid 89); 30 Apr 2018 14:24:37 -0000 Received: from c-24-0-179-87.hsd1.nj.comcast.net (HELO iMac.local) (jan@digitaldaemon.com@24.0.179.87) by digitaldaemon.com with SMTP; 30 Apr 2018 14:24:37 -0000 Subject: Re: Getting pthread names To: =?UTF-8?Q?Manuel_St=c3=bchn?= , freebsd-hackers@freebsd.org References: <20180430111434.GA18085@freebsd-t450.fritz.box> From: Jan Knepper Message-ID: <7d26b9d2-0f1e-2103-941a-c9c608b4e4fa@digitaldaemon.com> Date: Mon, 30 Apr 2018 10:24:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180430111434.GA18085@freebsd-t450.fritz.box> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:24:46 -0000 I think the pthread_set_name_np(3) function is for debugging (reporting) purposes. The names show up when you use 'procstat', 'top', 'ps', etc. If you want to give a thread a name and use that name later in code why not keep that internally in you thread management structures/code and use that same name in the call to pthread_set_name_np? ManiaC++ Jan Knepper On 04/30/2018 07:14, Manuel Stühn wrote: > Hi, > > for setting a name for pthreads i found pthread_set_name_np(3), but > for retrieving the name i found nothing. Is there any api like > pthread_getname_np for FreeBSD? Or is there another way to retrieve > the threads name within an application? > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Apr 30 14:43:21 2018 Return-Path: Delivered-To: freebsd-hackers@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 54627FAD12A for ; Mon, 30 Apr 2018 14:43:21 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id F2FD170355 for ; Mon, 30 Apr 2018 14:43:20 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 973CA5646F; Mon, 30 Apr 2018 09:43:14 -0500 (CDT) Subject: Re: new laptop, no sound in spite of driver attaching To: Wojciech Puchar , freebsd-hackers@freebsd.org References: From: Eric van Gyzen Openpgp: preference=signencrypt Message-ID: <83d82ee4-ea07-1082-e4d9-a969a8588167@vangyzen.net> Date: Mon, 30 Apr 2018 09:43:10 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:43:21 -0000 On 04/30/2018 06:58, Wojciech Puchar wrote: > and no idea where to search for a solution > > FreeBSD laptop.wojtek.intra 11.1-STABLE FreeBSD 11.1-STABLE #2: Mon Apr > 30 13:35:54 CEST 2018 > root@laptop.wojtek.intra:/usr/src/sys/amd64/compile/laptop  amd64 > > > in dmesg > hdac0: mem 0x91410000-0x91413fff irq 22 > at device 27.0 on pci0 > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 20 and 25 on hdaa0 > pcm1: at nid 33 and 18 on hdaa0 > hdacc1: at cad 2 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm2: at nid 5 on hdaa1 > > > tried to change hw.snd.default_unit to 0, 1 or 2 - no sound in any case. > > mixer when default_unit is 0 > > Mixer vol      is currently set to  65:65 > Mixer pcm      is currently set to 100:100 > Mixer speaker  is currently set to 100:100 > Mixer mic      is currently set to   0:0 > Mixer mix      is currently set to 100:100 > Mixer rec      is currently set to   0:0 > Mixer igain    is currently set to   0:0 > Mixer ogain    is currently set to 100:100 > Recording source: mic > > > mixer when default_unit is 1 > > Mixer vol      is currently set to 100:100 > Mixer pcm      is currently set to 100:100 > Mixer rec      is currently set to  37:37 > Mixer igain    is currently set to   0:0 > Mixer monitor  is currently set to  56:56 > > mixer when default_unit is 2 > > Mixer vol      is currently set to 100:100 > Mixer pcm      is currently set to 100:100 > > this is HP 250 G5 laptop HDA is apparently very difficult for vendors to get right. Linux has thousands of lines of vendor- and model-specific patches to fix it. Start here: https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c If you're lucky, you'll find a patch for your laptop or a similar laptop that has the same problem(s). The next step is to figure out how to express the patch in FreeBSD's driver. Hopefully, someone will take interest in porting many of Linux's HDA patches to FreeBSD. Sound is probably one of the top three reasons people fail to run FreeBSD on their laptop. Eric From owner-freebsd-hackers@freebsd.org Mon Apr 30 14:53:38 2018 Return-Path: Delivered-To: freebsd-hackers@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 32402FAD526 for ; Mon, 30 Apr 2018 14:53:38 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCC007325E for ; Mon, 30 Apr 2018 14:53:37 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [IPv6:2600:1:f45e:b478:dd3a:c418:c4d8:a451] (unknown [IPv6:2600:1:f45e:b478:dd3a:c418:c4d8:a451]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 7545B335C80; Mon, 30 Apr 2018 14:53:32 +0000 (UTC) Mime-Version: 1.0 (1.0) Subject: Re: Getting pthread names From: Richard Yao X-Mailer: iPhone Mail (15E302) In-Reply-To: <7d26b9d2-0f1e-2103-941a-c9c608b4e4fa@digitaldaemon.com> Date: Mon, 30 Apr 2018 10:53:26 -0400 Cc: =?utf-8?Q?Manuel_St=C3=BChn?= , freebsd-hackers@freebsd.org Message-Id: <64966B3E-41FE-44A5-A85D-A96EF89B22ED@gentoo.org> References: <20180430111434.GA18085@freebsd-t450.fritz.box> <7d26b9d2-0f1e-2103-941a-c9c608b4e4fa@digitaldaemon.com> To: Jan Knepper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:53:38 -0000 > On Apr 30, 2018, at 10:24 AM, Jan Knepper wrote: >=20 > I think the pthread_set_name_np(3) function is for debugging (reporting) p= urposes. It is. >=20 > The names show up when you use 'procstat', 'top', 'ps', etc. >=20 > If you want to give a thread a name and use that name later in code why no= t keep that internally in you thread management structures/code and use that= same name in the call to pthread_set_name_np? I cannot speak for him, but sometimes it is easier to just let the OS do stu= ff for you. That being said, if that is what he wants, it would be trivial t= o do using thread specific data: https://docs.oracle.com/cd/E19120-01/open.solaris/816-5137/tlib-40012/index.= html The GNU extension is just a special case of TSD that was implemented to aid d= ebugging as far as I can tell. It is separate from the pthreads functionalit= y for implementing this though. >=20 > ManiaC++ > Jan Knepper >=20 >=20 >=20 >> On 04/30/2018 07:14, Manuel St=C3=BChn wrote: >> Hi, >>=20 >> for setting a name for pthreads i found pthread_set_name_np(3), but for r= etrieving the name i found nothing. Is there any api like pthread_getname_np= for FreeBSD? Or is there another way to retrieve the threads name within an= application? >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Mon Apr 30 14:57:49 2018 Return-Path: Delivered-To: freebsd-hackers@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 B510CFAD6E7 for ; Mon, 30 Apr 2018 14:57:49 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51DAD741CB for ; Mon, 30 Apr 2018 14:57:49 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [IPv6:2600:1:f45e:b478:dd3a:c418:c4d8:a451] (unknown [IPv6:2600:1:f45e:b478:dd3a:c418:c4d8:a451]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id BB55A335C8A; Mon, 30 Apr 2018 14:57:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: new laptop, no sound in spite of driver attaching From: Richard Yao X-Mailer: iPhone Mail (15E302) In-Reply-To: <83d82ee4-ea07-1082-e4d9-a969a8588167@vangyzen.net> Date: Mon, 30 Apr 2018 10:57:41 -0400 Cc: Wojciech Puchar , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <83d82ee4-ea07-1082-e4d9-a969a8588167@vangyzen.net> To: Eric van Gyzen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:57:49 -0000 > On Apr 30, 2018, at 10:43 AM, Eric van Gyzen wrote: >=20 >> On 04/30/2018 06:58, Wojciech Puchar wrote: >> and no idea where to search for a solution >>=20 >> FreeBSD laptop.wojtek.intra 11.1-STABLE FreeBSD 11.1-STABLE #2: Mon Apr >> 30 13:35:54 CEST 2018 >> root@laptop.wojtek.intra:/usr/src/sys/amd64/compile/laptop amd64 >>=20 >>=20 >> in dmesg >> hdac0: mem 0x91410000-0x91413fff irq 22 >> at device 27.0 on pci0 >> hdacc0: at cad 0 on hdac0 >> hdaa0: at nid 1 on hdacc0 >> pcm0: at nid 20 and 25 on hdaa0 >> pcm1: at nid 33 and 18 on hdaa0 >> hdacc1: at cad 2 on hdac0 >> hdaa1: at nid 1 on hdacc1 >> pcm2: at nid 5 on hdaa1 >>=20 >>=20 >> tried to change hw.snd.default_unit to 0, 1 or 2 - no sound in any case. >>=20 >> mixer when default_unit is 0 >>=20 >> Mixer vol is currently set to 65:65 >> Mixer pcm is currently set to 100:100 >> Mixer speaker is currently set to 100:100 >> Mixer mic is currently set to 0:0 >> Mixer mix is currently set to 100:100 >> Mixer rec is currently set to 0:0 >> Mixer igain is currently set to 0:0 >> Mixer ogain is currently set to 100:100 >> Recording source: mic >>=20 >>=20 >> mixer when default_unit is 1 >>=20 >> Mixer vol is currently set to 100:100 >> Mixer pcm is currently set to 100:100 >> Mixer rec is currently set to 37:37 >> Mixer igain is currently set to 0:0 >> Mixer monitor is currently set to 56:56 >>=20 >> mixer when default_unit is 2 >>=20 >> Mixer vol is currently set to 100:100 >> Mixer pcm is currently set to 100:100 >>=20 >> this is HP 250 G5 laptop >=20 > HDA is apparently very difficult for vendors to get right. Linux has > thousands of lines of vendor- and model-specific patches to fix it. > Start here: >=20 > https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.= c >=20 > If you're lucky, you'll find a patch for your laptop or a similar laptop > that has the same problem(s). The next step is to figure out how to > express the patch in FreeBSD's driver. >=20 > Hopefully, someone will take interest in porting many of Linux's HDA > patches to FreeBSD. Sound is probably one of the top three reasons > people fail to run FreeBSD on their laptop. What are the other two? Graphics support and easy management of WiFi? I hate to say that, but those are the two that kept me from adopting Gentoo = FreeBSD on my laptop when I wanted to install it several years ago. The inte= l sandy bridge graphics support was new enough that it had not really made i= t downstream to Gentoo FreeBSD and the lack of a network manager equivalent f= or doing easy connection and disconnection to WiFi networks from a BSD userl= and was a headache. :/ >=20 > Eric > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Mon Apr 30 15:15:19 2018 Return-Path: Delivered-To: freebsd-hackers@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 C5754FADF0F for ; Mon, 30 Apr 2018 15:15:19 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6D69276E35 for ; Mon, 30 Apr 2018 15:15:18 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 4D4455646F; Mon, 30 Apr 2018 10:15:18 -0500 (CDT) Subject: Re: new laptop, no sound in spite of driver attaching To: Richard Yao Cc: freebsd-hackers@freebsd.org, Wojciech Puchar References: <83d82ee4-ea07-1082-e4d9-a969a8588167@vangyzen.net> From: Eric van Gyzen Openpgp: preference=signencrypt Message-ID: <9aabed2a-17c2-231f-3091-9f37126222e1@vangyzen.net> Date: Mon, 30 Apr 2018 10:15:17 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 15:15:20 -0000 On 04/30/2018 09:57, Richard Yao wrote: > > >> On Apr 30, 2018, at 10:43 AM, Eric van Gyzen wrote: >> >>> On 04/30/2018 06:58, Wojciech Puchar wrote: >>> and no idea where to search for a solution >>> >>> FreeBSD laptop.wojtek.intra 11.1-STABLE FreeBSD 11.1-STABLE #2: Mon Apr >>> 30 13:35:54 CEST 2018 >>> root@laptop.wojtek.intra:/usr/src/sys/amd64/compile/laptop amd64 >>> >>> >>> in dmesg >>> hdac0: mem 0x91410000-0x91413fff irq 22 >>> at device 27.0 on pci0 >>> hdacc0: at cad 0 on hdac0 >>> hdaa0: at nid 1 on hdacc0 >>> pcm0: at nid 20 and 25 on hdaa0 >>> pcm1: at nid 33 and 18 on hdaa0 >>> hdacc1: at cad 2 on hdac0 >>> hdaa1: at nid 1 on hdacc1 >>> pcm2: at nid 5 on hdaa1 >>> >>> >>> tried to change hw.snd.default_unit to 0, 1 or 2 - no sound in any case. >>> >>> mixer when default_unit is 0 >>> >>> Mixer vol is currently set to 65:65 >>> Mixer pcm is currently set to 100:100 >>> Mixer speaker is currently set to 100:100 >>> Mixer mic is currently set to 0:0 >>> Mixer mix is currently set to 100:100 >>> Mixer rec is currently set to 0:0 >>> Mixer igain is currently set to 0:0 >>> Mixer ogain is currently set to 100:100 >>> Recording source: mic >>> >>> >>> mixer when default_unit is 1 >>> >>> Mixer vol is currently set to 100:100 >>> Mixer pcm is currently set to 100:100 >>> Mixer rec is currently set to 37:37 >>> Mixer igain is currently set to 0:0 >>> Mixer monitor is currently set to 56:56 >>> >>> mixer when default_unit is 2 >>> >>> Mixer vol is currently set to 100:100 >>> Mixer pcm is currently set to 100:100 >>> >>> this is HP 250 G5 laptop >> >> HDA is apparently very difficult for vendors to get right. Linux has >> thousands of lines of vendor- and model-specific patches to fix it. >> Start here: >> >> https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c >> >> If you're lucky, you'll find a patch for your laptop or a similar laptop >> that has the same problem(s). The next step is to figure out how to >> express the patch in FreeBSD's driver. >> >> Hopefully, someone will take interest in porting many of Linux's HDA >> patches to FreeBSD. Sound is probably one of the top three reasons >> people fail to run FreeBSD on their laptop. > > What are the other two? Graphics support and easy management of WiFi? I would say graphics and suspend/resume. WiFi management is certainly an annoyance, but if the hardware works, I can cope with that. If the sound hardware doesn't work, it's useless (until I can find the time to study /two/ HDA drivers). Granted, I had to replace the Atheros card in my XPS 13 with an Intel, but that was only 19 USD and about 20 minutes, so that was also just an annoyance. > I hate to say that, but those are the two that kept me from adopting Gentoo FreeBSD on my laptop when I wanted to install it several years ago. The intel sandy bridge graphics support was new enough that it had not really made it downstream to Gentoo FreeBSD and the lack of a network manager equivalent for doing easy connection and disconnection to WiFi networks from a BSD userland was a headache. :/ I'm really grateful for all the recent graphics work. Without it, my XPS 13 would be running Linux for sure. I would thank people by name, but I would miss some. You know who you are. :) Eric From owner-freebsd-hackers@freebsd.org Mon Apr 30 15:51:20 2018 Return-Path: Delivered-To: freebsd-hackers@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 27D3EFAEC34 for ; Mon, 30 Apr 2018 15:51:20 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 94CE77FEB6 for ; Mon, 30 Apr 2018 15:51:18 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w3UFpKJP015134 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Apr 2018 17:51:20 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w3UFpEi3015131; Mon, 30 Apr 2018 17:51:14 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Mon, 30 Apr 2018 17:51:14 +0200 (CEST) From: Wojciech Puchar To: Eric van Gyzen cc: Richard Yao , freebsd-hackers@freebsd.org, Wojciech Puchar Subject: Re: new laptop, no sound in spite of driver attaching In-Reply-To: <9aabed2a-17c2-231f-3091-9f37126222e1@vangyzen.net> Message-ID: References: <83d82ee4-ea07-1082-e4d9-a969a8588167@vangyzen.net> <9aabed2a-17c2-231f-3091-9f37126222e1@vangyzen.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 15:51:20 -0000 will this output from mpg123 be helpful? am i missing something in kernel or actually i need a realtek patch you gave me a link in kernel messages i've got pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead or it's some other problem? mpg123 -Cv Astral_Projection_-_In_The_Mix_Cd1_-_Sundown_-_01_-_Another_World.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.25.0; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes Decoder: x86-64 (SSE) Trying output module: oss, device: Terminal control enabled, press 'h' for listing of keys and functions. Playing MPEG stream 1 of 1: Astral_Projection_-_In_The_Mix_Cd1_-_Sundown_-_01_-_Another_World.mp3 ... [src/libmpg123/id3.c:465] error: No comment text / valid description? MPEG 1.0 L III cbr192 44100 j-s Title: Another World (Floorplay Remix) Artist: Astral Projection Comment: Sundown) Album: In The Mix (CD1 - Sundown) Year: 2000 Genre: Trance > 0008+6891 00:00.20+03:00.01 --- 100=100 192 kb/s 627 B acc 2 clip p+0.000 [src/libout123/libout123.c:654] error: Error in writing audio (Invalid argument?)! main: [src/mpg123.c:809] error: Deep trouble! Cannot flush to my output anymore! From owner-freebsd-hackers@freebsd.org Mon Apr 30 15:54:40 2018 Return-Path: Delivered-To: freebsd-hackers@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 749CFFAEF3F for ; Mon, 30 Apr 2018 15:54:40 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D286817C2 for ; Mon, 30 Apr 2018 15:54:39 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [IPv6:2600:1:f45e:b478:dd3a:c418:c4d8:a451] (unknown [IPv6:2600:1:f45e:b478:dd3a:c418:c4d8:a451]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 62731335C86; Mon, 30 Apr 2018 15:54:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: new laptop, no sound in spite of driver attaching From: Richard Yao X-Mailer: iPhone Mail (15E302) In-Reply-To: <9aabed2a-17c2-231f-3091-9f37126222e1@vangyzen.net> Date: Mon, 30 Apr 2018 11:54:30 -0400 Cc: freebsd-hackers@freebsd.org, Wojciech Puchar Content-Transfer-Encoding: quoted-printable Message-Id: References: <83d82ee4-ea07-1082-e4d9-a969a8588167@vangyzen.net> <9aabed2a-17c2-231f-3091-9f37126222e1@vangyzen.net> To: Eric van Gyzen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 15:54:40 -0000 > On Apr 30, 2018, at 11:15 AM, Eric van Gyzen wrote: >=20 >> On 04/30/2018 09:57, Richard Yao wrote: >>=20 >>=20 >>>> On Apr 30, 2018, at 10:43 AM, Eric van Gyzen wrote:= >>>>=20 >>>> On 04/30/2018 06:58, Wojciech Puchar wrote: >>>> and no idea where to search for a solution >>>>=20 >>>> FreeBSD laptop.wojtek.intra 11.1-STABLE FreeBSD 11.1-STABLE #2: Mon Apr= >>>> 30 13:35:54 CEST 2018 >>>> root@laptop.wojtek.intra:/usr/src/sys/amd64/compile/laptop amd64 >>>>=20 >>>>=20 >>>> in dmesg >>>> hdac0: mem 0x91410000-0x91413fff irq 22= >>>> at device 27.0 on pci0 >>>> hdacc0: at cad 0 on hdac0 >>>> hdaa0: at nid 1 on hdacc0 >>>> pcm0: at nid 20 and 25 on hdaa0 >>>> pcm1: at nid 33 and 18 on hdaa0 >>>> hdacc1: at cad 2 on hdac0 >>>> hdaa1: at nid 1 on hdacc1 >>>> pcm2: at nid 5 on hdaa1 >>>>=20 >>>>=20 >>>> tried to change hw.snd.default_unit to 0, 1 or 2 - no sound in any case= . >>>>=20 >>>> mixer when default_unit is 0 >>>>=20 >>>> Mixer vol is currently set to 65:65 >>>> Mixer pcm is currently set to 100:100 >>>> Mixer speaker is currently set to 100:100 >>>> Mixer mic is currently set to 0:0 >>>> Mixer mix is currently set to 100:100 >>>> Mixer rec is currently set to 0:0 >>>> Mixer igain is currently set to 0:0 >>>> Mixer ogain is currently set to 100:100 >>>> Recording source: mic >>>>=20 >>>>=20 >>>> mixer when default_unit is 1 >>>>=20 >>>> Mixer vol is currently set to 100:100 >>>> Mixer pcm is currently set to 100:100 >>>> Mixer rec is currently set to 37:37 >>>> Mixer igain is currently set to 0:0 >>>> Mixer monitor is currently set to 56:56 >>>>=20 >>>> mixer when default_unit is 2 >>>>=20 >>>> Mixer vol is currently set to 100:100 >>>> Mixer pcm is currently set to 100:100 >>>>=20 >>>> this is HP 250 G5 laptop >>>=20 >>> HDA is apparently very difficult for vendors to get right. Linux has >>> thousands of lines of vendor- and model-specific patches to fix it. >>> Start here: >>>=20 >>> https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realte= k.c >>>=20 >>> If you're lucky, you'll find a patch for your laptop or a similar laptop= >>> that has the same problem(s). The next step is to figure out how to >>> express the patch in FreeBSD's driver. >>>=20 >>> Hopefully, someone will take interest in porting many of Linux's HDA >>> patches to FreeBSD. Sound is probably one of the top three reasons >>> people fail to run FreeBSD on their laptop. >>=20 >> What are the other two? Graphics support and easy management of WiFi? >=20 > I would say graphics and suspend/resume. WiFi management is certainly > an annoyance, but if the hardware works, I can cope with that. If the > sound hardware doesn't work, it's useless (until I can find the time to > study /two/ HDA drivers). >=20 > Granted, I had to replace the Atheros card in my XPS 13 with an Intel, > but that was only 19 USD and about 20 minutes, so that was also just an > annoyance. Certain laptops have BIOS whitelists that prevent people from doing that wit= hout flashing coreboot modifying the BIOS. You were lucky. >=20 >> I hate to say that, but those are the two that kept me from adopting Gent= oo FreeBSD on my laptop when I wanted to install it several years ago. The i= ntel sandy bridge graphics support was new enough that it had not really mad= e it downstream to Gentoo FreeBSD and the lack of a network manager equivale= nt for doing easy connection and disconnection to WiFi networks from a BSD u= serland was a headache. :/ >=20 > I'm really grateful for all the recent graphics work. Without it, my > XPS 13 would be running Linux for sure. I would thank people by name, > but I would miss some. You know who you are. :) >=20 > Eric > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Mon Apr 30 17:49:57 2018 Return-Path: Delivered-To: freebsd-hackers@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 89522FB1CBF for ; Mon, 30 Apr 2018 17:49:57 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 3489D7BF22 for ; Mon, 30 Apr 2018 17:49:57 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: (qmail 2411 invoked by uid 89); 30 Apr 2018 17:49:54 -0000 Received: from c-24-0-179-87.hsd1.nj.comcast.net (HELO iMac.local) (jan@digitaldaemon.com@24.0.179.87) by digitaldaemon.com with SMTP; 30 Apr 2018 17:49:54 -0000 Subject: Re: Getting pthread names To: Richard Yao Cc: =?UTF-8?Q?Manuel_St=c3=bchn?= , freebsd-hackers@freebsd.org References: <20180430111434.GA18085@freebsd-t450.fritz.box> <7d26b9d2-0f1e-2103-941a-c9c608b4e4fa@digitaldaemon.com> <64966B3E-41FE-44A5-A85D-A96EF89B22ED@gentoo.org> From: Jan Knepper Message-ID: Date: Mon, 30 Apr 2018 13:49:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <64966B3E-41FE-44A5-A85D-A96EF89B22ED@gentoo.org> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 17:49:57 -0000 On 04/30/2018 10:53, Richard Yao wrote: > > > On Apr 30, 2018, at 10:24 AM, Jan Knepper > wrote: > >> I think the pthread_set_name_np(3) function is for debugging >> (reporting) purposes. > > It is. :-) >> >> The names show up when you use 'procstat', 'top', 'ps', etc. >> >> If you want to give a thread a name and use that name later in code >> why not keep that internally in you thread management structures/code >> and use that same name in the call to pthread_set_name_np? > > I cannot speak for him, but sometimes it is easier to just let the OS > do stuff for you. That being said, if that is what he wants, it would > be trivial to do using thread specific data: My experience as a software engineer is... If the OS or (standard) library can do something for you, let the OS or (standard) library do it. So, agreed. It is also 'trivial' to do when you have any form or thread management or any form of thread data. Indeed using a 'thread specific data' solution might be helpful. > >> >> On 04/30/2018 07:14, Manuel Stühn wrote: >>> Hi, >>> >>> for setting a name for pthreads i found pthread_set_name_np(3), but >>> for retrieving the name i found nothing. Is there any api like >>> pthread_getname_np for FreeBSD? Or is there another way to retrieve >>> the threads name within an application? >>> >>> _______________________________________________ >> ManiaC++ Jan Knepper From owner-freebsd-hackers@freebsd.org Mon Apr 30 18:47:22 2018 Return-Path: Delivered-To: freebsd-hackers@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 C2A91FB35D4 for ; Mon, 30 Apr 2018 18:47:22 +0000 (UTC) (envelope-from james.wright@jigsawdezign.com) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB8A86DF0 for ; Mon, 30 Apr 2018 18:47:21 +0000 (UTC) (envelope-from james.wright@jigsawdezign.com) Received: from [192.168.0.15] ([82.18.193.38]) by mrelayeu.kundenserver.de (mreue002 [212.227.15.163]) with ESMTPSA (Nemesis) id 0LkG7v-1efY2S0DDn-00cR0R for ; Mon, 30 Apr 2018 20:47:15 +0200 Subject: Re: new laptop, no sound in spite of driver attaching To: freebsd-hackers@freebsd.org References: <83d82ee4-ea07-1082-e4d9-a969a8588167@vangyzen.net> <9aabed2a-17c2-231f-3091-9f37126222e1@vangyzen.net> From: James Wright Message-ID: <1fb3f697-b0b6-69e1-ec16-cb0214c9487e@jigsawdezign.com> Date: Mon, 30 Apr 2018 19:47:19 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Provags-ID: V03:K1:nBkTzBPA05DHOD3fTkuu6m0JtiWCTenQTDRrs/Y+B+XL0hV+gPG CKlcNGUSPT2ThJo7LZA+3Qt+L0OlNPY6g3fOqqMtfU94qWAGN5L8286fZj8tzS0Z0BegDFM Leb+Aeq8rbkA5wMG5+QW/tqeq7nzwmw9WgP72Ml7amOt7ftavp2MxArcBKo5Ks3JqmgRjUC hFd9nX+SjgAQ1Na3zq5kg== X-UI-Out-Filterresults: notjunk:1;V01:K0:YBnskVNifoo=:S8gAPmo5Naj/h27N3LAPs0 oEZSNsSfAFeQqyqD6jJKBln41gGof2k8mSZo3IMGDwB5+LY8Eo04y9r85YCoH4pIc2l9oiFw5 nVUsrHUg37NPLelipfhu9KFvAfi6OOac/ql0EKTVyj4bTOs6iwSGy1NBpVas3CArP3z8337Nx A5XzshAhr67UWfNpyW4nbSq0Wzudx+6zVxEfceQi27zaRRkl5qEQSK7T9a43D7ZVRaqGtmn0i VJuRe7X4CxRRe3n0N8yBHwBakQWB9r1zdVknGc/2pyM5yAbkTwW+EV5ZxjmiDkgWMvdLYTjjQ L/qy6s9B/HSe4ALDxuhXz4gItkfMNY4zdb+A7eID43P1Y5Jhzig4f7sqrYArLg2fl71o81Yym VhjYBTYNKxLrzuu1WR1Px+dRpWvDbdbI3Y0Go1UZsctECS45tMEoQRfmQIkQdZqGP3ppUiDUy gw2IxO2tN7n8deY3q8tde4hb8zyfJoZ3WkfmefXE91OLz5YPG2CErnq2OQhI/KA2qbyWc//z6 Ct9Qj9P2VQ7dYf8GysLW/EWxiSerLayIv49T7Bm6r3sTMH/9FxcEyEPrDCtSMOidCUUPJh5HP NzL+7eeE7jpa0kVuN+u93VbAYmLJn2KKWEMmxEmdhzIm3NX7zrbP/h/fLGHaAudS1CdDZjReZ d4SKDan0qq2Cf5gZW6gSNLuMtasGDTma51eSa2p9wCg/QYIiITdx84AsUtTJE7S8S39ZhNN3r mMEf0x46vgQJ6ry9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 18:47:23 -0000 To get sound working on my MacbookAir I have the following in "/boot/loader.conf" # Fix audio output not getting any voltage, see: man snd_hda hint.hdaa.1.config="ovref" hint.hdaa.1.gpio_config="0=set" # Assign Headphones (nid16) to same "as" group as Speakers with seq=15 to enable switching between them hint.hdaa.1.nid16.config="as=1 seq=15" Had to use the time old method of Trial and Error using various combinations of values for the first two lines until it finally worked! Probably won't be the same values for your laptop, but might give you a path of enquiry... PS: I'm deeply grateful for the work done on bringing the i915 driver upto scratch for Intel Broadwell, it has meant I can now use FreeBSD as my main OS on this laptop everyday with fantastic battery life too (~16 hours!) On 30/04/2018 16:54, Richard Yao wrote: > >> On Apr 30, 2018, at 11:15 AM, Eric van Gyzen wrote: >> >>> On 04/30/2018 09:57, Richard Yao wrote: >>> >>> >>>>> On Apr 30, 2018, at 10:43 AM, Eric van Gyzen wrote: >>>>> >>>>> On 04/30/2018 06:58, Wojciech Puchar wrote: >>>>> and no idea where to search for a solution >>>>> >>>>> FreeBSD laptop.wojtek.intra 11.1-STABLE FreeBSD 11.1-STABLE #2: Mon Apr >>>>> 30 13:35:54 CEST 2018 >>>>> root@laptop.wojtek.intra:/usr/src/sys/amd64/compile/laptop amd64 >>>>> >>>>> >>>>> in dmesg >>>>> hdac0: mem 0x91410000-0x91413fff irq 22 >>>>> at device 27.0 on pci0 >>>>> hdacc0: at cad 0 on hdac0 >>>>> hdaa0: at nid 1 on hdacc0 >>>>> pcm0: at nid 20 and 25 on hdaa0 >>>>> pcm1: at nid 33 and 18 on hdaa0 >>>>> hdacc1: at cad 2 on hdac0 >>>>> hdaa1: at nid 1 on hdacc1 >>>>> pcm2: at nid 5 on hdaa1 >>>>> >>>>> >>>>> tried to change hw.snd.default_unit to 0, 1 or 2 - no sound in any case. >>>>> >>>>> mixer when default_unit is 0 >>>>> >>>>> Mixer vol is currently set to 65:65 >>>>> Mixer pcm is currently set to 100:100 >>>>> Mixer speaker is currently set to 100:100 >>>>> Mixer mic is currently set to 0:0 >>>>> Mixer mix is currently set to 100:100 >>>>> Mixer rec is currently set to 0:0 >>>>> Mixer igain is currently set to 0:0 >>>>> Mixer ogain is currently set to 100:100 >>>>> Recording source: mic >>>>> >>>>> >>>>> mixer when default_unit is 1 >>>>> >>>>> Mixer vol is currently set to 100:100 >>>>> Mixer pcm is currently set to 100:100 >>>>> Mixer rec is currently set to 37:37 >>>>> Mixer igain is currently set to 0:0 >>>>> Mixer monitor is currently set to 56:56 >>>>> >>>>> mixer when default_unit is 2 >>>>> >>>>> Mixer vol is currently set to 100:100 >>>>> Mixer pcm is currently set to 100:100 >>>>> >>>>> this is HP 250 G5 laptop >>>> HDA is apparently very difficult for vendors to get right. Linux has >>>> thousands of lines of vendor- and model-specific patches to fix it. >>>> Start here: >>>> >>>> https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c >>>> >>>> If you're lucky, you'll find a patch for your laptop or a similar laptop >>>> that has the same problem(s). The next step is to figure out how to >>>> express the patch in FreeBSD's driver. >>>> >>>> Hopefully, someone will take interest in porting many of Linux's HDA >>>> patches to FreeBSD. Sound is probably one of the top three reasons >>>> people fail to run FreeBSD on their laptop. >>> What are the other two? Graphics support and easy management of WiFi? >> I would say graphics and suspend/resume. WiFi management is certainly >> an annoyance, but if the hardware works, I can cope with that. If the >> sound hardware doesn't work, it's useless (until I can find the time to >> study /two/ HDA drivers). >> >> Granted, I had to replace the Atheros card in my XPS 13 with an Intel, >> but that was only 19 USD and about 20 minutes, so that was also just an >> annoyance. > Certain laptops have BIOS whitelists that prevent people from doing that without flashing coreboot modifying the BIOS. You were lucky. >>> I hate to say that, but those are the two that kept me from adopting Gentoo FreeBSD on my laptop when I wanted to install it several years ago. The intel sandy bridge graphics support was new enough that it had not really made it downstream to Gentoo FreeBSD and the lack of a network manager equivalent for doing easy connection and disconnection to WiFi networks from a BSD userland was a headache. :/ >> I'm really grateful for all the recent graphics work. Without it, my >> XPS 13 would be running Linux for sure. I would thank people by name, >> but I would miss some. You know who you are. :) >> >> Eric >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Apr 30 19:27:19 2018 Return-Path: Delivered-To: freebsd-hackers@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 9D59CFB4664 for ; Mon, 30 Apr 2018 19:27:19 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3712E6FF46; Mon, 30 Apr 2018 19:27:19 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1fDESD-0007Ds-U5; Mon, 30 Apr 2018 21:27:17 +0200 Received: from [::1] (port=44966 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1fDESD-0001vH-QG; Mon, 30 Apr 2018 21:27:17 +0200 Received: from mx4.freenet.de ([195.4.92.14]:35468) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1fDEQ8-0008Pd-F5; Mon, 30 Apr 2018 21:25:08 +0200 Received: from p4fd9e53a.dip0.t-ipconnect.de ([79.217.229.58]:53633 helo=freebsd-t450.fritz.box) by mx4.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (port 587) (Exim 4.90_1 #2) id 1fDEQ8-0008IU-B6; Mon, 30 Apr 2018 21:25:08 +0200 Date: Mon, 30 Apr 2018 21:25:06 +0200 From: Manuel =?iso-8859-15?Q?St=FChn?= To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: Getting pthread names Message-ID: <20180430192506.GA86258@freebsd-t450.fritz.box> References: <20180430111434.GA18085@freebsd-t450.fritz.box> <20180430135711.GT6887@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20180430135711.GT6887@kib.kiev.ua> User-Agent: Mutt/1.9.5 (2018-04-13) X-Spamscore: -3.1 (---) X-Spamreport: Action: no action Symbol: NEURAL_HAM(-0.00) Symbol: ASN(0.00) Symbol: RCVD_VIA_SMTP_AUTH(0.00) Symbol: RCVD_TLS_ALL(0.00) Symbol: RCVD_COUNT_ONE(0.00) Symbol: FROM_HAS_DN(0.00) Symbol: FROM_EQ_ENVFROM(0.00) Symbol: BAYES_HAM(-3.00) Symbol: MIME_GOOD(-0.10) Symbol: TO_DN_SOME(0.00) Symbol: TO_MATCH_ENVRCPT_ALL(0.00) Symbol: RCPT_COUNT_TWO(0.00) Message-ID: 20180430192506.GA86258@freebsd-t450.fritz.box X-FN-Spambar: X-Originated-At: 79.217.229.58!53633 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 19:27:19 -0000 On Mon, Apr 30, 2018 at 04:57:11PM +0300, Konstantin Belousov wrote: >On Mon, Apr 30, 2018 at 01:14:34PM +0200, Manuel St?hn wrote: >> Hi, >> >> for setting a name for pthreads i found pthread_set_name_np(3), but for >> retrieving the name i found nothing. Is there any api like >> pthread_getname_np for FreeBSD? Or is there another way to retrieve the >> threads name within an application? > >Not like pthread_getname_np(), but still something. You can use >(binary) sysctl kern.proc.pid. to get struct kinfo_proc for all >threads. In the structure, the ki_tdname() member contains the thread >name as set by pthread_set_name_np(3). Thank you (all) for your answer(s) and hints! I'll have a look into this. BR Manuel From owner-freebsd-hackers@freebsd.org Mon Apr 30 19:28:29 2018 Return-Path: Delivered-To: freebsd-hackers@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 209A7FB4704; Mon, 30 Apr 2018 19:28:29 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4A970016; Mon, 30 Apr 2018 19:28:28 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id p18-v6so9059479wrm.1; Mon, 30 Apr 2018 12:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lqDxgS6LEk2217+ZmszifI7YY3uRNOnfBe7WmYQaJKI=; b=JOSqI70zsQ0pwHwXGhEitI5bfGqQ7GuVqAhuVn63R8Dp8zeGNpQgYVopytOYcbH0jw YccdD89CZxNGDp93K+UF6U7TgFtq+t7TzT93Noo9pLfI8O7Amf9L6ShL08EP6kNfyEA9 pmrl/NeZRrP9/xK4EzHxwM60AYOnue18n1LqU7Azlwc4R8QY8smRxkKrPS6g321igT4u rzkLp4xJyst/bvjwRenwbBymy1NfaS2NTop2CHSxyEQuLR5heTU+DV3gNzt6Kt32yKLW unm0eiVB6QFk4T26sIHNYWSFQg6xqUdGrwV9HeE7jsZlpuQY68uNkElAXTzGJa+Q/h7q PUiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lqDxgS6LEk2217+ZmszifI7YY3uRNOnfBe7WmYQaJKI=; b=pKq6N0zhDzJFj/TWUmRzwxUBja+tLzAEnCnBRh+ictAmRo5iZKeNw1OaWWW4cpECWf S/+txNlFmO5WQw8jcsXjouxbc7Gk/+PC9nANNM7yWwa22oQr9SNsVbUa8s6QggBvJEID G+NBXODjrTpulObKUkkXIiDrtXviah79MBZkZxqLcMVQVzScqFiSB+InsPSwa+VRJXp7 PYrQENbom8tPetGGwV+p0oi4J1FsuOekABc+GPs3AKRrurG+iofvc4S/5IEgFajrnQj6 NjbBMkWxGJLbyPn2W5MoPHVAtS6HLiUr1S8yZ/aFVYg6ZMrxXJM4QFcTUHuKCpgdQ+Nl 0NLw== X-Gm-Message-State: ALQs6tCIwdR5qIZGZZzD6hVdYFaz5QfqvUH5dKkX8uKMc2Zy519RJtwX lUXLyR0b2h+J1NhTmx4hzmupTHZI/x1gIdVt3craOw== X-Google-Smtp-Source: AB8JxZr5TXGCcVrW4LJzyTPWE7CoZc6HtdWozEAZn22h0wyUx4N/0aV3CDNhdNqQih9WeL44lm29UZEO4jktROYPwMc= X-Received: by 2002:adf:c4a6:: with SMTP id m35-v6mr9705429wrf.103.1525116507333; Mon, 30 Apr 2018 12:28:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.171.232 with HTTP; Mon, 30 Apr 2018 12:27:46 -0700 (PDT) In-Reply-To: References: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> From: "Jack L." Date: Mon, 30 Apr 2018 12:27:46 -0700 Message-ID: Subject: Re: Can we please finally solve Dell's racadm for FreeBSD? Advice needed To: "Peter G." Cc: FreeBSD Hackers , freebsd-amd64@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 19:28:29 -0000 I have device ipmi in my kernel config (or you can just kldload ipmi). Install ipmitool, and most of the dell cmds are the usual ipmi commands. Some commands might have to be sent via raw or delloem and you can't soft reset the drac, only hard reset it via the tool. On Sun, Apr 29, 2018 at 7:28 AM, Peter G. wrote: > On 29/04/2018 05:08, Jack L. wrote: >> I manage a variety of Dell servers running FreeBSD, only 610 and 1950s >> work with racadm but everything that can be done with racadm can also >> be done with ipmitool. I just use ipmitool to get around instead of >> their proprietary racadm stuff. What functionality do you need from >> racadm and maybe I can give you an ipmitool equivalent? > > It seems I may missed the ipmi angle altogether assuming it was only > remote. Only now following Dan's comments I am realizing how racadm > works talking to local hardware. > > You mean using this impi(4) as a local device and talking to it via > local tool allowing coms with the device? Oh, that would do nicely. I > need this for scripting mostly, e.g. monitoring what the intrusion > sensor shows. > > Can you please describe your setup? What other kernel modules and 3rd > party software do you employ? Any tricks with device.hints are needed? I > have a small R220 at hand for testing, but it's lacking impi(4) > altogether. Will have to rebuild. > > -- > PG From owner-freebsd-hackers@freebsd.org Tue May 1 01:43:32 2018 Return-Path: Delivered-To: freebsd-hackers@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 C5D5BFBD3C4 for ; Tue, 1 May 2018 01:43:32 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 592FF800E5 for ; Tue, 1 May 2018 01:43:32 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id p3-v6so12259904itc.0 for ; Mon, 30 Apr 2018 18:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gizn8MBF99MZj7pv+sXaNJIUMh9MopiZWrsCC3MV3A8=; b=Kq6LFD/uYeAKmIC8eHuWy94lOYoXBZD2ZTScJBJ88cCnkU2q278aWRjFYbvycMcCHa OnZc1VFLBF9bmgCYkBjE92qMLf+AEHnYsoSafH2L3hbvyURpME74Kw3uucSDVcRqTzXi +pXODsCdT41uKyltRyD9JgfB/0KMjwRIQoKW32thDe7wxbcy3gQIyTWHREBxq6aiNlZP LkmUABEp+AP2D/R2CiNcmKSY+RYv9zyr91wpKu7wWqDUngDCjKzVbtIon5Yv/abapnkw 4ysq9tebMcne2uO4U0GFo/axrGrAA+Sc2HVAcmFibGC6lfqpQ6vYSh961kjh13+J578F lUsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gizn8MBF99MZj7pv+sXaNJIUMh9MopiZWrsCC3MV3A8=; b=MfRm8Q5PBLSbRKWX+pi2hFNH9eUItM1AKaufGHj9DPocPf/KIACY2NVSjBEdyBhkW/ GA7Bi6TwqgwRdac4HT4SAPoBhuOGB0bjuKkb+MNh3wByqV6tBRtSzZfmfaiA2pIshps/ V0mkrIUveZf6RjY1VSuj9mVDzblkoLJ3Ve9+gzM6dPzQSyKQo20zobdOmMa0kSM8VvPf yui/0DrhnVlvdtQvVhHUFeKE75tAmiSZQLrVEn/0cYGZj5bUrC35+FUF3WditADs+poj aUgl3Fmt7VaGq932LlFEJgONjLM7bA9buRbtmE+ufDYByNXK3mIKPjf3fQz4ouSwOTgv WHHQ== X-Gm-Message-State: ALQs6tA2fHKMw7KQTqFmJaOeWv9LZrO6SehmRx2zQKWQ1BehJ7gm7p8h w329EhUzd/eNHPnhpMo2p7qMVeKr5uXf11lajosnwQ== X-Google-Smtp-Source: AB8JxZpWdqBqHiCxViRYZwNvCY6VGw/KaongyLPgYLjup/gv+AtaXDdlLAapEE7SbngMFGAPbBSj0oqmcNGAUMj3Qw8= X-Received: by 2002:a24:558b:: with SMTP id e133-v6mr13991437itb.18.1525139011580; Mon, 30 Apr 2018 18:43:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:8d57:0:0:0:0:0 with HTTP; Mon, 30 Apr 2018 18:43:30 -0700 (PDT) In-Reply-To: References: From: Adam Date: Mon, 30 Apr 2018 20:43:30 -0500 Message-ID: Subject: Re: new laptop, no sound in spite of driver attaching To: Wojciech Puchar Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 01:43:33 -0000 On Mon, Apr 30, 2018 at 6:58 AM, Wojciech Puchar wrote: > and no idea where to search for a solution > > FreeBSD laptop.wojtek.intra 11.1-STABLE FreeBSD 11.1-STABLE #2: Mon Apr 30 > 13:35:54 CEST 2018 root@laptop.wojtek.intra:/usr/src/sys/amd64/compile/laptop > amd64 > > > in dmesg > hdac0: mem 0x91410000-0x91413fff irq 22 at > device 27.0 on pci0 > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 20 and 25 on hdaa0 > pcm1: at nid 33 and 18 on hdaa0 > hdacc1: at cad 2 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm2: at nid 5 on hdaa1 > > > tried to change hw.snd.default_unit to 0, 1 or 2 - no sound in any case. > > mixer when default_unit is 0 > > Mixer vol is currently set to 65:65 > Mixer pcm is currently set to 100:100 > Mixer speaker is currently set to 100:100 > Mixer mic is currently set to 0:0 > Mixer mix is currently set to 100:100 > Mixer rec is currently set to 0:0 > Mixer igain is currently set to 0:0 > Mixer ogain is currently set to 100:100 > Recording source: mic > > > mixer when default_unit is 1 > > Mixer vol is currently set to 100:100 > Mixer pcm is currently set to 100:100 > Mixer rec is currently set to 37:37 > Mixer igain is currently set to 0:0 > Mixer monitor is currently set to 56:56 > > mixer when default_unit is 2 > > Mixer vol is currently set to 100:100 > Mixer pcm is currently set to 100:100 > Here is mine: hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20 and 18 on hdaa0 pcm1: at nid 27 and 25 on hdaa0 pcm2: at nid 30 on hdaa0 For me, I have to tickle the following sysctl's to get expected sound. hw.snd.vpc_0db hw.snd.vpc_reset hw.snd.vpc_autoreset -- Adam From owner-freebsd-hackers@freebsd.org Tue May 1 01:21:09 2018 Return-Path: Delivered-To: freebsd-hackers@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 08C7CFBBD51 for ; Tue, 1 May 2018 01:21:09 +0000 (UTC) (envelope-from daniel.nelson@influxdata.com) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F0AD7BD50 for ; Tue, 1 May 2018 01:21:08 +0000 (UTC) (envelope-from daniel.nelson@influxdata.com) Received: by mail-pf0-x234.google.com with SMTP id v63so8099036pfk.8 for ; Mon, 30 Apr 2018 18:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=influxdata-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bghUMlxaWgAJamGj7CsonJJ11UJaz/A6nj1AmhImG9s=; b=yFpZ85tNz8r5M02Z6+rUu1LmxPKgtQPxBqD8H3vGWrS3Fg0YELU3HJY1mQAcMMuC4s AzCDgFmslbsgy9wDk/Ejxy4wl525Urnp+xF7z9HB91UbCh+SerqkZ0ArMK3Kcuxlf0ze D9e4oTQkw512IUFtk1y9iTd61CGvVOFFcNOEVmOfbahMzxDxn+rxgOuQBJ0v6K/6XSuF G0tZyQ0+MSy52q+PXvZtvKI3uIWWrS0VoqYNuGyXXBEQuaO3BE3S1/iJfzWEJFvi3hVG o8LkPHOSc0MCU+yM99x4mWBBynmgMyUkzmW9WXAHxCwlgZSdeY/ssA4LqIOQwJK2NApW yMVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bghUMlxaWgAJamGj7CsonJJ11UJaz/A6nj1AmhImG9s=; b=RdFJeLFvpS8XnBnwc+uLVL/XhdkfdAk8C2cSZuHJAZYq7EP33XgOaKv9gy1R32c8CM AS5V2dg5AFUA3DXBaYn0bxgQTF9VoG3FLDROPQn9EDSXhE+Fgwg6x2Qin/NOb3xdCdvz GPnpUh2YUN/htr8tGTfmQFLsq+FWA/qofUGu11/359QpFOb5N/hrKcJP9Z23s1ppjvAl QNIYafoYDHUWdEQGKihlCFY/J2xnI7qe65gYwFunMmxiPyLY/QyKsf9PYga1k6qFEtxD eEy3s3rpHhSj0hIY60X9ir0ovmGcdTY0yRF4MXoI1jYWgujysYhdiWJ2mOZJlDiCzcG0 wY0g== X-Gm-Message-State: ALQs6tApt2DP0gVWMflMSvP9PAiOBRIHiMi3u+zE6D+ps5qPRRc8Ngjx VB5V1oqfKtPnxPQLK7h7hWezZWWqnH4= X-Google-Smtp-Source: AB8JxZpQzHFNp6Y+4E+4oP9pP8vc18QfCiTYSxsLTb92td3IByyWQMwVSMiTaxhVsRvhVDehdSiJ8A== X-Received: by 10.98.231.16 with SMTP id s16mr13903540pfh.227.1525137667491; Mon, 30 Apr 2018 18:21:07 -0700 (PDT) Received: from localhost (108-67-146-180.lightspeed.sntcca.sbcglobal.net. [108.67.146.180]) by smtp.gmail.com with ESMTPSA id n4sm15078013pfn.2.2018.04.30.18.21.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 18:21:06 -0700 (PDT) From: Daniel Nelson X-Google-Original-From: Daniel Nelson Date: Mon, 30 Apr 2018 18:21:04 -0700 To: Ed Schouten Cc: Eitan Adler , FreeBSD Hackers Subject: Re: "Sysctl as a Service" for influxdb / telegraf Message-ID: <20180501012104.GA23663@loaner> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Mailman-Approved-At: Tue, 01 May 2018 02:46:19 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 01:21:09 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 30, 2018 at 12:01:54AM +0200, Ed Schouten wrote: > Considering this and the ongoing standardisation effort, maybe it > makes more sense to stick to a single exporter? We can consider > extending the man page to mention that it can also be used in > combination with Telegraf. I am supportive of doing this with either the Prometheus format or via InfluxDB Line Protocol. There are a few minor advantages in using Line Protocol from Telegraf's persepective involving performance and the elimination of any confusion transforming metrics, but they probably don't outweigh the need to support yet another format on your end. Telegraf aims to be unopinionated so that it can support heterogeneous environments. -- Daniel --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEdMTdXPVQblRpgloJyq1ZyURPYVUFAlrnwQAACgkQyq1ZyURP YVUNmg/+KAuiop1oN6bnDBRMKfqm6GcZ5cylL6I/+GgGRj6N99a+zHdXTARLBqYY oUr7BpzwSlfis6WLoErJGdwpirqylBEvZAWpqXnNd7hDx2hKoUOMdhArG7L8oTvH cg0OSsTORePUINZeu4CexwgF6aw7NurbgId/CuRRtyd/EALH42J6Pl3R8pN5ghC8 aP2dAhPkqxMp46cgn4WM6VtYtui48hEp9Im/JVIt/WMxRPpOE2Sp8Wfl8v8TCT8/ M/neXsLw/xnyNtxUzrR62q7G+BUZ5bA+4kXAD9FghjJzNBgk9p6ex8VL8fv03VSJ xHgXZMQKilkYL6SkmnBlE+MoFjgArzehAu7+4RUWiS8BZnhVNKR9jvsCOmv9wBo3 6XzY2uQvHnevfm2A2Bd8CVQKm589ZVaDwLmcvJFSjFLe4v+j78KpG0IjWLYYQaNY dfKFHKyzPK6dBcXW+GPlyLOTuYh2n9Csi8RXEJz1RZq1jwEKx6axbzN7yqo/HQRf krBdaVVJC7MBfKfgf2Es6JjP+KNDJVgtthNcL4O4UWJxvYqQCPDpEID+vajaw4f6 Tu0Vl2m37qHD7elmNNBTTmaelmR/qXesVjmJU0bTH4ANIDg15k3uEa0kJwVQHQxv ohjGTI+uD2x9MeaEpHoZZyUBWGKXXAD2emFn5SKv+PJztmiq6a4= =roZU -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-hackers@freebsd.org Tue May 1 11:11:16 2018 Return-Path: Delivered-To: freebsd-hackers@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 531C3FA75D8 for ; Tue, 1 May 2018 11:11:16 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D48FD69068 for ; Tue, 1 May 2018 11:11:15 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w41BBIJr021821 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 May 2018 13:11:18 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w41BBDVR021818; Tue, 1 May 2018 13:11:13 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Tue, 1 May 2018 13:11:13 +0200 (CEST) From: Wojciech Puchar To: James Wright cc: freebsd-hackers@freebsd.org Subject: Re: new laptop, no sound in spite of driver attaching In-Reply-To: <1fb3f697-b0b6-69e1-ec16-cb0214c9487e@jigsawdezign.com> Message-ID: References: <83d82ee4-ea07-1082-e4d9-a969a8588167@vangyzen.net> <9aabed2a-17c2-231f-3091-9f37126222e1@vangyzen.net> <1fb3f697-b0b6-69e1-ec16-cb0214c9487e@jigsawdezign.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 11:11:16 -0000 > To get sound working on my MacbookAir I have the following in > "/boot/loader.conf" > > # Fix audio output not getting any voltage, see: man snd_hda > hint.hdaa.1.config="ovref" > hint.hdaa.1.gpio_config="0=set" > lots of tries but i think it's not a problem because of pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead so it doesn't seem like sound not being directed properly but dma/irq problem. > # Assign Headphones (nid16) to same "as" group as Speakers with seq=15 to > enable switching between them > hint.hdaa.1.nid16.config="as=1 seq=15" > > Had to use the time old method of Trial and Error using various combinations > of values for the first two lines until it finally worked! > > Probably won't be the same values for your laptop, but might give you a path > of enquiry... > > PS: I'm deeply grateful for the work done on bringing the i915 driver upto > scratch for Intel Broadwell, i installed /usr/ports/graphics/drm-stable-kmod to get working intel graphics. but works fine now. > it has meant I can now use FreeBSD as my main OS on this laptop everyday with > fantastic battery life too (~16 hours!) > > > On 30/04/2018 16:54, Richard Yao wrote: >> >>> On Apr 30, 2018, at 11:15 AM, Eric van Gyzen wrote: >>> >>>> On 04/30/2018 09:57, Richard Yao wrote: >>>> >>>> >>>>>> On Apr 30, 2018, at 10:43 AM, Eric van Gyzen wrote: >>>>>> >>>>>> On 04/30/2018 06:58, Wojciech Puchar wrote: >>>>>> and no idea where to search for a solution >>>>>> >>>>>> FreeBSD laptop.wojtek.intra 11.1-STABLE FreeBSD 11.1-STABLE #2: Mon Apr >>>>>> 30 13:35:54 CEST 2018 >>>>>> root@laptop.wojtek.intra:/usr/src/sys/amd64/compile/laptop amd64 >>>>>> >>>>>> >>>>>> in dmesg >>>>>> hdac0: mem 0x91410000-0x91413fff irq 22 >>>>>> at device 27.0 on pci0 >>>>>> hdacc0: at cad 0 on hdac0 >>>>>> hdaa0: at nid 1 on hdacc0 >>>>>> pcm0: at nid 20 and 25 on hdaa0 >>>>>> pcm1: at nid 33 and 18 on hdaa0 >>>>>> hdacc1: at cad 2 on hdac0 >>>>>> hdaa1: at nid 1 on hdacc1 >>>>>> pcm2: at nid 5 on hdaa1 >>>>>> >>>>>> >>>>>> tried to change hw.snd.default_unit to 0, 1 or 2 - no sound in any >>>>>> case. >>>>>> >>>>>> mixer when default_unit is 0 >>>>>> >>>>>> Mixer vol is currently set to 65:65 >>>>>> Mixer pcm is currently set to 100:100 >>>>>> Mixer speaker is currently set to 100:100 >>>>>> Mixer mic is currently set to 0:0 >>>>>> Mixer mix is currently set to 100:100 >>>>>> Mixer rec is currently set to 0:0 >>>>>> Mixer igain is currently set to 0:0 >>>>>> Mixer ogain is currently set to 100:100 >>>>>> Recording source: mic >>>>>> >>>>>> >>>>>> mixer when default_unit is 1 >>>>>> >>>>>> Mixer vol is currently set to 100:100 >>>>>> Mixer pcm is currently set to 100:100 >>>>>> Mixer rec is currently set to 37:37 >>>>>> Mixer igain is currently set to 0:0 >>>>>> Mixer monitor is currently set to 56:56 >>>>>> >>>>>> mixer when default_unit is 2 >>>>>> >>>>>> Mixer vol is currently set to 100:100 >>>>>> Mixer pcm is currently set to 100:100 >>>>>> >>>>>> this is HP 250 G5 laptop >>>>> HDA is apparently very difficult for vendors to get right. Linux has >>>>> thousands of lines of vendor- and model-specific patches to fix it. >>>>> Start here: >>>>> >>>>> https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c >>>>> >>>>> If you're lucky, you'll find a patch for your laptop or a similar laptop >>>>> that has the same problem(s). The next step is to figure out how to >>>>> express the patch in FreeBSD's driver. >>>>> >>>>> Hopefully, someone will take interest in porting many of Linux's HDA >>>>> patches to FreeBSD. Sound is probably one of the top three reasons >>>>> people fail to run FreeBSD on their laptop. >>>> What are the other two? Graphics support and easy management of WiFi? >>> I would say graphics and suspend/resume. WiFi management is certainly >>> an annoyance, but if the hardware works, I can cope with that. If the >>> sound hardware doesn't work, it's useless (until I can find the time to >>> study /two/ HDA drivers). >>> >>> Granted, I had to replace the Atheros card in my XPS 13 with an Intel, >>> but that was only 19 USD and about 20 minutes, so that was also just an >>> annoyance. >> Certain laptops have BIOS whitelists that prevent people from doing that >> without flashing coreboot modifying the BIOS. You were lucky. >>>> I hate to say that, but those are the two that kept me from adopting >>>> Gentoo FreeBSD on my laptop when I wanted to install it several years >>>> ago. The intel sandy bridge graphics support was new enough that it had >>>> not really made it downstream to Gentoo FreeBSD and the lack of a network >>>> manager equivalent for doing easy connection and disconnection to WiFi >>>> networks from a BSD userland was a headache. :/ >>> I'm really grateful for all the recent graphics work. Without it, my >>> XPS 13 would be running Linux for sure. I would thank people by name, >>> but I would miss some. You know who you are. :) >>> >>> Eric >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Tue May 1 11:14:22 2018 Return-Path: Delivered-To: freebsd-hackers@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 52F85FA7D1F for ; Tue, 1 May 2018 11:14:22 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7A1F69437 for ; Tue, 1 May 2018 11:14:21 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w41BEOCJ022075 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 May 2018 13:14:24 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w41BEJff022072; Tue, 1 May 2018 13:14:19 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Tue, 1 May 2018 13:14:19 +0200 (CEST) From: Wojciech Puchar To: Adam cc: Wojciech Puchar , FreeBSD Hackers Subject: Re: new laptop, no sound in spite of driver attaching In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 11:14:22 -0000 > Here is mine: > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 20 and 18 on hdaa0 > pcm1: at nid 27 and 25 on hdaa0 > pcm2: at nid 30 on hdaa0 > > For me, I have to tickle the following sysctl's to get expected sound. > > hw.snd.vpc_0db > hw.snd.vpc_reset > hw.snd.vpc_autoreset > i tried this without results i think it is different problem. kernel: pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead From owner-freebsd-hackers@freebsd.org Tue May 1 12:10:16 2018 Return-Path: Delivered-To: freebsd-hackers@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 3C666FAA1F4 for ; Tue, 1 May 2018 12:10:16 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F193764B3 for ; Tue, 1 May 2018 12:10:15 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w41CADg9026805 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 1 May 2018 14:10:13 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w41CA83H026802 for ; Tue, 1 May 2018 14:10:08 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Tue, 1 May 2018 14:10:08 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: more info Re: new laptop, no sound in spite of driver attaching In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 12:10:16 -0000 this is what i get attempting to playing sound. pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [65536] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=235 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=256 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=470 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=512 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=2730 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=2730 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=2730 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [65536] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=2730 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=2730 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=2730 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [65536] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1365 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [65536] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [65536] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=1881 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=1024 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=4096 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=4096 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=4096 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [65536] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=4096 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=4096 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=4096 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [65536] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [32768] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [65536] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [4096] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [8192] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=682 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 sndbuf_remalloc(): b=0xfffff80006d9a600 131072 [16384] NOCHANGE pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 pcm0: chn_start(): PCMDIR_PLAY (virtual) threshold i=5015 j=4 pcm0: chn_start(): VCHAN PARENT starting! (PCMDIR_PLAY/running) (ready=4096 force=1 i=1 j=0 intrtimeout=21 latency=21ms) hdac0: 1536Kbps of 46080Kbps bandwidth used pcm0: PCMDIR_PLAY: Stream setup fmt=00200010 (2.0) speed=48000 pcm0: PCMDIR_PLAY: Stream setup nid=2: fmt=0x0011, dfmt=0x0001, chan=0x0010, chan_count=0x01, stripe=0 pcm0: chn_trigger() pcm0:play:dsp0.p0: calling go=0x00000001 , prev=0xffffffff pcm0: chn_trigger() pcm0:virtual:dsp0.vp0: calling go=0x00000001 , prev=0xffffffff pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead pcm0: chn_trigger() pcm0:play:dsp0.p0: calling go=0xffffffff , prev=0x00000001 pcm0: chn_trigger() pcm0:virtual:dsp0.vp0: calling go=0xffffffff , prev=0x00000001 pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 From owner-freebsd-hackers@freebsd.org Tue May 1 13:17:03 2018 Return-Path: Delivered-To: freebsd-hackers@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 BA44FFABAD3 for ; Tue, 1 May 2018 13:17:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 21F3682CE1 for ; Tue, 1 May 2018 13:17:02 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w41DH7WJ032752 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 1 May 2018 15:17:07 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w41DH1jI032747 for ; Tue, 1 May 2018 15:17:02 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Tue, 1 May 2018 15:17:01 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: SOLVED Re: new laptop, no sound in spite of driver attaching Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 13:17:03 -0000 setting dev.hdac.0.polling=1 did a workaround of a problem. From owner-freebsd-hackers@freebsd.org Tue May 1 17:26:37 2018 Return-Path: Delivered-To: freebsd-hackers@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 7DCEAFB13B1 for ; Tue, 1 May 2018 17:26:37 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13FD079BBA for ; Tue, 1 May 2018 17:26:37 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.alameda.xse.com; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.alameda.xse.com (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w41HQW69024199 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 1 May 2018 10:26:34 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.alameda.xse.com To: FreeBSD Hackers From: Craig Leres Subject: Porting questions Message-ID: Date: Tue, 1 May 2018 10:26:32 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3886E7E3D311105AF941B91A" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.0 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-8611-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:26:37 -0000 This is a multi-part message in MIME format. --------------3886E7E3D311105AF941B91A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'm working a port for the Espressif ESP32 toolchain so I can move development of some projects (FreeRTOS and Arduino) from Ubuntu to FreeBSD. I have a few questions. (1) Naming: The pre-built linux 64 bit toolchain is called: xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz so I thought the port should be called xtensa-esp32-elf; is this a reasonable name? (2) Port version: The toolchain is built from the latest version: https://github.com/espressif/crosstool-NG There is not a release that corresponds to this version; is it legit for me to use: DISTVERSION= 1.22.0-80-g6c4433a5 GH_TUPLE= espressif:crosstool-NG:${DISTVERSION} which apparently gives me 1.22.0.80.g6.c4433.a5 as the PORTVERSION? (3) USES=gcc doesn't provide a binary named gcc: crosstool-NG has the string "gcc" firmly baked into it. When I have USES=gcc (today) I get gcc6 but without patching a ton of files I need gcc to exist when poudriere is building. I solved this by also adding: BUILD_DEPENDS+= gcc:lang/gcc but it seems wrong to me that USES=gcc doesn't provide a binary named gcc. (4) How to handle downloads that shouldn't be extracted: The toolchain uses specific versions of a bunch of things: TARBALLS= \ binutils-2.25.1.tar.bz2 \ expat-2.1.0.tar.gz \ gcc-5.2.0.tar.bz2 \ gdb-7.10.tar.xz \ gmp-6.0.0a.tar.xz \ isl-0.14.tar.xz \ mpc-1.0.3.tar.gz \ mpfr-3.1.3.tar.xz \ ncurses-6.0.tar.gz \ newlib-2.2.0.tar.gz Normally the build process downloads these which doesn't work well with poudriere; you don't want to download these every time you build port. I put copies in my /usr/ports/distfiles and add symlinks to the work tree in post-extract and later the build script correctly skips downloading them when it finds them already there. I'd like to add these to DISTFILES for auto-download and checksums but I don't want them extracted by do-extract. Is my best option to override the do-extract target? I've attached the current version of the Makefile for informal review. Craig --------------3886E7E3D311105AF941B91A Content-Type: text/plain; charset=UTF-8; name="Makefile" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Makefile" IyBDcmVhdGVkIGJ5OiBDcmFpZyBMZXJlcyA8bGVyZXNAZnJlZWJzZC5vcmc+CiMgJEZyZWVC U0QkCgpQT1JUTkFNRT0JeHRlbnNhLWVzcDMyLWVsZgpESVNUVkVSU0lPTj0JMS4yMi4wLTgw LWc2YzQ0MzNhNQpDQVRFR09SSUVTPQlkZXZlbAojRElTVEZJTEVTPQojTUFTVEVSX1NJVEVT PQlTRgpESVNUX1NVQkRJUj0JeHRlbnNhLWVzcDMyLWVsZgoKTUFJTlRBSU5FUj0JbGVyZXNA ZnJlZWJzZC5vcmcKQ09NTUVOVD0JVG9vbGNoYWluIGZvciB4dGVuc2EtZXNwMzItZWxmCgpM SUNFTlNFPQlHUEx2MiBMR1BMMjEKTElDRU5TRV9DT01CPQltdWx0aQoKQlVJTERfREVQRU5E Uys9CWJhc2g6c2hlbGxzL2Jhc2ggXAoJCWdhd2s6bGFuZy9nYXdrIFwKCQlnY2M6bGFuZy9n Y2MgXAoJCWdpdDpkZXZlbC9naXQgXAoJCWdwYXRjaDpkZXZlbC9wYXRjaCBcCgkJJHtMT0NB TEJBU0V9L2Jpbi9ncmVwOnRleHRwcm9jL2dudWdyZXAgXAoJCWdwZXJmOmRldmVsL2dwZXJm IFwKCQlnc2VkOnRleHRwcm9jL2dzZWQgXAoJCWhlbHAybWFuOm1pc2MvaGVscDJtYW4gXAoJ CW1ha2VpbmZvOnByaW50L3RleGluZm8gXAoJCXdnZXQ6ZnRwL3dnZXQKClVTRVM9CQlhdXRv cmVjb25mOmJ1aWxkIGJpc29uIGdtYWtlIGxpYnRvb2wgcHl0aG9uOmJ1aWxkClVTRV9HSVRI VUI9CXllcwpHSF9UVVBMRT0JZXNwcmVzc2lmOmNyb3NzdG9vbC1ORzoke0RJU1RWRVJTSU9O fQpVU0VfR0NDPQl5ZXMKClRBUkJBTExTPSBcCgkJYmludXRpbHMtMi4yNS4xLnRhci5iejIg XAoJCWV4cGF0LTIuMS4wLnRhci5neiBcCgkJZ2NjLTUuMi4wLnRhci5iejIgXAoJCWdkYi03 LjEwLnRhci54eiBcCgkJZ21wLTYuMC4wYS50YXIueHogXAoJCWlzbC0wLjE0LnRhci54eiBc CgkJbXBjLTEuMC4zLnRhci5neiBcCgkJbXBmci0zLjEuMy50YXIueHogXAoJCW5jdXJzZXMt Ni4wLnRhci5neiBcCgkJbmV3bGliLTIuMi4wLnRhci5negoKcG9zdC1leHRyYWN0OgoJJHtN S0RJUn0gJHtCVUlMRF9XUktTUkN9Ly5idWlsZC90YXJiYWxscwouZm9yIEYgaW4gJChUQVJC QUxMUykKCSR7TE59IC1zICR7RElTVERJUn0vJHtESVNUX1NVQkRJUn0vJHtGfSAke0JVSUxE X1dSS1NSQ30vLmJ1aWxkL3RhcmJhbGxzCi5lbmRmb3IKCnByZS1jb25maWd1cmU6CgkgY2Qg JHtCVUlMRF9XUktTUkN9ICYmIC4vYm9vdHN0cmFwCgpkby1jb25maWd1cmU6CgljZCAke0JV SUxEX1dSS1NSQ30gJiYgXAoJICAgIC4vY29uZmlndXJlIC0tZW5hYmxlLWxvY2FsIC0td2l0 aC1ncmVwPSR7TE9DQUxCQVNFfS9iaW4vZ3JlcAoKcHJlLWJ1aWxkOgoJY2QgJHtCVUlMRF9X UktTUkN9ICYmIFwKCSAgICAke1NFVEVOVn0gLXVNQUtFTEVWRUwgLXVNQUtFRkxBR1MgLXUu TUFLRS5MRVZFTC5FTlYgXAoJICAgICAke01BS0VfQ01EfSBpbnN0YWxsICYmIC4vY3Qtbmcg eHRlbnNhLWVzcDMyLWVsZgoKZG8tYnVpbGQ6CgljZCAke0JVSUxEX1dSS1NSQ30gJiYgQ1Rf QUxMT1dfQlVJTERfQVNfUk9PVF9TVVJFPTEgLi9jdC1uZyBidWlsZAoKLmluY2x1ZGUgPGJz ZC5wb3J0Lm1rPgo= --------------3886E7E3D311105AF941B91A-- From owner-freebsd-hackers@freebsd.org Tue May 1 18:04:22 2018 Return-Path: Delivered-To: freebsd-hackers@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 2A57EFB26C4 for ; Tue, 1 May 2018 18:04:22 +0000 (UTC) (envelope-from lebarondemerde@privacychain.ch) Received: from forward103o.mail.yandex.net (forward103o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::606]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45AB184221 for ; Tue, 1 May 2018 18:04:20 +0000 (UTC) (envelope-from lebarondemerde@privacychain.ch) Received: from mxback12g.mail.yandex.net (mxback12g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:91]) by forward103o.mail.yandex.net (Yandex) with ESMTP id EA0B05881D6C for ; Tue, 1 May 2018 21:04:08 +0300 (MSK) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [2a02:6b8:0:1a2d::28]) by mxback12g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id CGGfzFYGDP-480CtDXj; Tue, 01 May 2018 21:04:08 +0300 Received: by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 4oBScjTgKN-468SF6IX; Tue, 01 May 2018 21:04:07 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Date: Tue, 1 May 2018 15:04:02 -0300 From: Le Baron =?utf-8?B?ZOKAmU1lcmRl?= To: freebsd-hackers@freebsd.org Subject: Re: Porting questions Message-ID: <20180501180402.e4kigr4f5qh44m6d@privacychain.ch> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180323 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:04:22 -0000 Hi! Ps. reviews.freebsd.org is a good place for that. :) On Tue, May 01, 2018 at 10:26:32AM -0700, Craig Leres wrote: > I'm working a port for the Espressif ESP32 toolchain so I can move > development of some projects (FreeRTOS and Arduino) from Ubuntu to FreeBSD. > I have a few questions. > > (1) Naming: The pre-built linux 64 bit toolchain is called: > > xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz > > so I thought the port should be called xtensa-esp32-elf; is this a > reasonable name? > > (2) Port version: The toolchain is built from the latest version: > > https://github.com/espressif/crosstool-NG > > There is not a release that corresponds to this version; is it legit for me > to use: > > DISTVERSION= 1.22.0-80-g6c4433a5 When upstream does not provide a version (or a separated commit will be used like HEAD), the version format to be used for GitHub is: gYYYYMMDD See 5.13: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description > GH_TUPLE= espressif:crosstool-NG:${DISTVERSION} I *think* GH_TAGNAME would be more aproppiated. > > which apparently gives me 1.22.0.80.g6.c4433.a5 as the PORTVERSION? > > (3) USES=gcc doesn't provide a binary named gcc: crosstool-NG has the string > "gcc" firmly baked into it. When I have USES=gcc (today) I get gcc6 but > without patching a ton of files I need gcc to exist when poudriere is > building. I solved this by also adding: > > BUILD_DEPENDS+= gcc:lang/gcc > > but it seems wrong to me that USES=gcc doesn't provide a binary named gcc. I didn't tried but ${REINPLACE_CMD} should do the job. See 4.4.3: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html > > (4) How to handle downloads that shouldn't be extracted: The toolchain uses > specific versions of a bunch of things: > > TARBALLS= \ > binutils-2.25.1.tar.bz2 \ > expat-2.1.0.tar.gz \ > gcc-5.2.0.tar.bz2 \ > gdb-7.10.tar.xz \ > gmp-6.0.0a.tar.xz \ > isl-0.14.tar.xz \ > mpc-1.0.3.tar.gz \ > mpfr-3.1.3.tar.xz \ > ncurses-6.0.tar.gz \ > newlib-2.2.0.tar.gz > > Normally the build process downloads these which doesn't work well with > poudriere; you don't want to download these every time you build port. I put > copies in my /usr/ports/distfiles and add symlinks to the work tree in > post-extract and later the build script correctly skips downloading them > when it finds them already there. I'd like to add these to DISTFILES for > auto-download and checksums but I don't want them extracted by do-extract. > Is my best option to override the do-extract target? I guess those are git submodules. GH_TUPLE are used for them. You can see a working example on x11/polybar > > I've attached the current version of the Makefile for informal review. > > Craig > # Created by: Craig Leres > # $FreeBSD$ > > PORTNAME= xtensa-esp32-elf > DISTVERSION= 1.22.0-80-g6c4433a5 > CATEGORIES= devel > #DISTFILES= > #MASTER_SITES= SF > DIST_SUBDIR= xtensa-esp32-elf > > MAINTAINER= leres@freebsd.org > COMMENT= Toolchain for xtensa-esp32-elf > > LICENSE= GPLv2 LGPL21 > LICENSE_COMB= multi > > BUILD_DEPENDS+= bash:shells/bash \ > gawk:lang/gawk \ > gcc:lang/gcc \ > git:devel/git \ > gpatch:devel/patch \ > ${LOCALBASE}/bin/grep:textproc/gnugrep \ > gperf:devel/gperf \ > gsed:textproc/gsed \ > help2man:misc/help2man \ > makeinfo:print/texinfo \ > wget:ftp/wget > > USES= autoreconf:build bison gmake libtool python:build > USE_GITHUB= yes > GH_TUPLE= espressif:crosstool-NG:${DISTVERSION} > USE_GCC= yes > > TARBALLS= \ > binutils-2.25.1.tar.bz2 \ > expat-2.1.0.tar.gz \ > gcc-5.2.0.tar.bz2 \ > gdb-7.10.tar.xz \ > gmp-6.0.0a.tar.xz \ > isl-0.14.tar.xz \ > mpc-1.0.3.tar.gz \ > mpfr-3.1.3.tar.xz \ > ncurses-6.0.tar.gz \ > newlib-2.2.0.tar.gz > > post-extract: > ${MKDIR} ${BUILD_WRKSRC}/.build/tarballs > .for F in $(TARBALLS) > ${LN} -s ${DISTDIR}/${DIST_SUBDIR}/${F} ${BUILD_WRKSRC}/.build/tarballs > .endfor > > pre-configure: > cd ${BUILD_WRKSRC} && ./bootstrap > > do-configure: > cd ${BUILD_WRKSRC} && \ > ./configure --enable-local --with-grep=${LOCALBASE}/bin/grep > > pre-build: > cd ${BUILD_WRKSRC} && \ > ${SETENV} -uMAKELEVEL -uMAKEFLAGS -u.MAKE.LEVEL.ENV \ > ${MAKE_CMD} install && ./ct-ng xtensa-esp32-elf > > do-build: > cd ${BUILD_WRKSRC} && CT_ALLOW_BUILD_AS_ROOT_SURE=1 ./ct-ng build > > .include > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Cheers! -- Best Regards. LBdM. From owner-freebsd-hackers@freebsd.org Tue May 1 18:07:59 2018 Return-Path: Delivered-To: freebsd-hackers@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 13CA8FB283A for ; Tue, 1 May 2018 18:07:59 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04D0584C50 for ; Tue, 1 May 2018 18:07:57 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id f65-v6so10443246itd.3 for ; Tue, 01 May 2018 11:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=nd97VYf+XHfiMC4mjTJIYfS6N2DkblaQreqC5mp+60o=; b=lIP8YWGqcDZJSr9u26+eEg3dmWSxEc2LV78a9nCD15I9A4xQofoVzunvg00Co7LD9I 3r5cWPLvGPAs836zabSSTxPrB+nPHEbykXBNVyf/sFymOdeSzrxztPKdY+c2srVEz5wr P+HKJ6w5lbytVWJDm5tQIzqO9dyXY72yxEcJPjmNPufNbMb+3PtQ2PO9W6Iu8HBGMcc+ bSDua5SowIGHrw6AF3gYXvYg326bFXN9yaJO81y09sMOvZYXrEJuDsO3toGz4p8m9JeV 0JWwDaEJjxlcoq6tn0MOZXjVPoILwwx0wiIvSQNk++keC/1QKWlEgDYV++YmX+EZj+GB foWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=nd97VYf+XHfiMC4mjTJIYfS6N2DkblaQreqC5mp+60o=; b=NkTxnvMIPEOcm6IAIXr0MLytXvV/ADo5qHnPqpyVPEQU9lYT5x+Gy9sKRSaIzzgYYl trbYx8+NlOWIl0//RrjJXNvbiQ2kEVGmBnvDEJBDzqMdMmv9nlWPSplDgvpd011T2rLN Sxl5QavdDP3zzHRpcTVPPAu2PntKVUg085U/atfc9lg2g8eBUoCG6XapxcXBLB6muJdk +Cm9fsACfvJRbgIeaDUqKRzLg8iPLCposfKppFA6rw8vEX5qkeA/s2P7rK7wr3rdvlAr VYy+TAXyaQhiXt7OEhKoSMo+GpGhb2+cbGp9Aar5AhQq/84p97IE2f5tCG0+zSizXepv mskA== X-Gm-Message-State: ALQs6tB4jCrTHoJXxly0DfQdhjja0bDU56Aqida8tzO79+yq5qxealKk qe0ldE2098S5iKDq7DZi9LxH0g== X-Google-Smtp-Source: AB8JxZq1ZRhPJ6fu9bSpuJEsNZPnw2WsqnU3P9M/DZrPlxw3QvTbUrm236OseCmHnie/oDOdlhmcBw== X-Received: by 2002:a24:ed4a:: with SMTP id r71-v6mr2165667ith.85.1525198076950; Tue, 01 May 2018 11:07:56 -0700 (PDT) Received: from [10.6.160.144] (rrcs-24-97-15-18.nys.biz.rr.com. [24.97.15.18]) by smtp.gmail.com with ESMTPSA id f6-v6sm5418393ioj.18.2018.05.01.11.07.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 11:07:56 -0700 (PDT) From: David Cross Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 1 May 2018 14:07:55 -0400 Subject: Bug 207069 (loader password kills boot) Message-Id: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> To: freebsd-hackers@freebsd.org X-Mailer: iPhone Mail (15E302) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:07:59 -0000 The aforementioned bug has been open for over 2 years, with attached and tes= ted patches. At least one other has commented.=20 Could we please have it for 11.2/12.0?= From owner-freebsd-hackers@freebsd.org Tue May 1 18:12:51 2018 Return-Path: Delivered-To: freebsd-hackers@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 1FCDAFB2B94 for ; Tue, 1 May 2018 18:12:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (unknown [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BAB3D8517E; Tue, 1 May 2018 18:12:50 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 761E22B9A4; Tue, 1 May 2018 18:12:50 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f44.google.com with SMTP id o123-v6so17284999lfe.8; Tue, 01 May 2018 11:12:50 -0700 (PDT) X-Gm-Message-State: ALQs6tCtV4Q3i5Toayu0uovswjDnmx73bMJVtaOenBBWV+akhXUvo9vN JB11KE55X96eEv21saLB3IvBY5zYSKcnYLODLYw= X-Google-Smtp-Source: AB8JxZrnRpveE8171KB0kSL1EDQSsqeMDpZSurFLu0Cw2HUoP0aTV3LPiJF2aAOKdwLpu2xtZOZgZF3w0DMLuN70jR0= X-Received: by 2002:a19:984d:: with SMTP id a74-v6mr10582965lfe.47.1525198368808; Tue, 01 May 2018 11:12:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Tue, 1 May 2018 11:12:28 -0700 (PDT) In-Reply-To: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> References: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> From: Kyle Evans Date: Tue, 1 May 2018 13:12:28 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Bug 207069 (loader password kills boot) To: David Cross Cc: FreeBSD Hackers , Devin Teske Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:12:51 -0000 On Tue, May 1, 2018 at 1:07 PM, David Cross wrote: > The aforementioned bug has been open for over 2 years, with attached and tested patches. At least one other has commented. > > Could we please have it for 11.2/12.0? Hi, CC'ing Devin, our local Forth-fu-fighter. If it looks ok to Devin, one of us should go ahead and shuffle this through. Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Tue May 1 18:16:14 2018 Return-Path: Delivered-To: freebsd-hackers@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 6E9F0FB2D1A for ; Tue, 1 May 2018 18:16:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0B438591F for ; Tue, 1 May 2018 18:16:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id d11-v6so14548565iof.11 for ; Tue, 01 May 2018 11:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=78ZrWvssdRCTA245Pgwi0CP9xfWfIjzNjDT0ORXgAKc=; b=iINvblQ+EtURJPOa5l8ores/fVhMj7BtANV2n9j7+rJDp6KpiWVptAU1BYj+mBHrWK CidtKxUg4RU7FExy72OLQgrWSMnS06Vyzk0Q35L8jxUpH54H/UwV4ycIdlPllsGW9Esq 9c2/OjGQ4zuvcsxjjVc3bGfVRowkIcNKEuSYAUfYDcsjPdEvSgU2v7VZuTZp5auwOYAY zjjlwjFO4a/T3atyj2Uhv5FUJW7D3wgoUo5Xd6gSqwgAAGO4VkD1Wn7MJcQlKCR3Pzfz +y44Ki15dwWQSCyGG2Jm8F/ZjfGkrYARnpzsI+74D8ZkdK1kMoHege+2EhGNkwfH1zmp YuNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=78ZrWvssdRCTA245Pgwi0CP9xfWfIjzNjDT0ORXgAKc=; b=Durc/sL6b8Pzp/KmANntDJXp8N4U1NblQUOOtkwV/wkOy1XQrrwGnjnGCSR3Kl1fnh rbaCX/x/ZTvxibJzrkSkz2/mHl90tR+OG4Ice5NpMAfw+/MB/yAZQkKCWC2IJduuf+bg n1B4wMrtgLXAKKwXRSbW+mkB9ay1KPOg5BAA3mR5KbMPWIObfVAaqHKUJPECeKwLhCwy RwWHOjc3a49b0dEwhIEif83Z0fz6NLzZLKPHi3kcHbYPqYEXCEmzi6xRNWK2M1YsuIkP r1qjV4DP8UTqgB64lM4w9Nl2ki1xlih1b4nu4q7WEpEm9OwNDbboAIhdvZs6cb7ZauKw eRpg== X-Gm-Message-State: ALQs6tDPX139kDZRvqWj5VAOXvu3W/uiiOZ27ACBpirGpCjk+IRsYjTg Lc+7EeuM7xZ7s3JtsxUI2KOCyqYjeIlR/Nn8ulDq4Q== X-Google-Smtp-Source: AB8JxZpZuxh9HQ7CUPXbRX717LL9tZAoNqvQs5I85Vr0D9zceR5rWajaZwV8W4U3gNQWUqOqYS7YeKbbOQ18wo2culc= X-Received: by 2002:a6b:5a0d:: with SMTP id o13-v6mr17318082iob.39.1525198573232; Tue, 01 May 2018 11:16:13 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Tue, 1 May 2018 11:16:12 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> References: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> From: Warner Losh Date: Tue, 1 May 2018 12:16:12 -0600 X-Google-Sender-Auth: w_Fb70jl-DkR9q5Y5BuNIdn0Pc4 Message-ID: Subject: Re: Bug 207069 (loader password kills boot) To: David Cross Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:16:14 -0000 It helps to mail the maintainer directly. I don't normally read hackers@. Had I missed this, the answer is likely no. However, why does the proposed patch fix things? It's not at all obvious. I'm very reluctant to push in 'works for me' patches I don't understand. Warner On Tue, May 1, 2018 at 12:07 PM, David Cross wrote: > The aforementioned bug has been open for over 2 years, with attached and > tested patches. At least one other has commented. > > Could we please have it for 11.2/12.0? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Tue May 1 18:17:37 2018 Return-Path: Delivered-To: freebsd-hackers@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 E929FFB2DDF for ; Tue, 1 May 2018 18:17:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70F0586618 for ; Tue, 1 May 2018 18:17:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id d11-v6so14552724iof.11 for ; Tue, 01 May 2018 11:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hcx8R0S5ZzoguZe++9l0uEW3CkbXcKLLbrS6l7cOOqU=; b=lxldPjjz8polVe+kzS8ze0io9TQEJdIvot7iAPAeCsnGPgUTHKt3yjQIoutHrPR+YI e4sBKPQqo4vSCueMpwUp3/z642cmj3d0zjw2szU5jOhUruc4PMw0aRI/yDxVnUHYIl7G gtsYUpzyIiBy7kkbP+lD2JpzxZ2/oLG4YkjBbNjhod7gJaaEYGF3laK9oWMLFFqIrFbL wb2nNlMeMlH+pw2BX1OaheDLdrItEw2W7YiRw2/dzR26Sxy6rTtczVJbcIU0yQfF9ydz wtN9HDVVMkhRbUWHZdekj3VLME8SnVb9/eh/YTzBQLOKPNYrCfFjVgXiv4J1r2MuNU/7 fy7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hcx8R0S5ZzoguZe++9l0uEW3CkbXcKLLbrS6l7cOOqU=; b=Ok7C8jN67VGcQs2SH8Hex9naFSp85KKrjIl08B2eFY0dtj8d37hHmIE62y2JhHH2zx Dxz3pIIw1IRR24/ufyeha36dIgHygyuHVitjeN8W7KnIjbkTK6cYC6IOYPscnK/7ZnsP Tp/Nz4wAvJlrJjQl9rFrvXsY5ePNCAmdEpU3+REeepb2GvZcl2kLeU+Ie8jU6XUkykIg gBEU1+6StWoQHAnjakCa0tKkgxffdtMntynXXGofJrDLpXEes7S6tj09Ww9VcpAgsku/ ySETrt3qMcW8AJFaaQXu5cuHZ3GMJ2bjKz7p4LJc0RlVjphQL9PYVda4+vxv+p5Q2Al9 dubA== X-Gm-Message-State: ALQs6tDm6O5b251wEwYSWT6oHAfu7niKmylRI820QTsn348uZlYMq2nZ d8mBLGsj19LuCQ9PYoHZNhvt/0L4BzbVMy4p95QfXA== X-Google-Smtp-Source: AB8JxZrxmoDR5btWEJTFz53QvQc7WFLprNNIoXZkm6vabAS2Qf74+SKWe8BFSheuxqZwUWsdevEFmmdHi1d+eIV/33I= X-Received: by 2002:a6b:3846:: with SMTP id f67-v6mr17529247ioa.117.1525198655883; Tue, 01 May 2018 11:17:35 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Tue, 1 May 2018 11:17:35 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> From: Warner Losh Date: Tue, 1 May 2018 12:17:35 -0600 X-Google-Sender-Auth: 6EW1WJkBD0AyaNvu_nFZwUXtc2c Message-ID: Subject: Re: Bug 207069 (loader password kills boot) To: Kyle Evans Cc: David Cross , FreeBSD Hackers , Devin Teske Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:17:37 -0000 On Tue, May 1, 2018 at 12:12 PM, Kyle Evans wrote: > On Tue, May 1, 2018 at 1:07 PM, David Cross wrote: > > The aforementioned bug has been open for over 2 years, with attached and > tested patches. At least one other has commented. > > > > Could we please have it for 11.2/12.0? > > Hi, > > CC'ing Devin, our local Forth-fu-fighter. If it looks ok to Devin, one > of us should go ahead and shuffle this through. > Yes. I've looked at this code a fair amount, and I don't understand why this is needed and why it would make things work. Since it is a security thing, I'm very reluctant to push it in absent better understanding of why it works. Warner From owner-freebsd-hackers@freebsd.org Tue May 1 18:22:28 2018 Return-Path: Delivered-To: freebsd-hackers@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 000D2FB32BF for ; Tue, 1 May 2018 18:22:27 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E6A468451; Tue, 1 May 2018 18:22:27 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 55ED82BAA0; Tue, 1 May 2018 18:22:27 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f49.google.com with SMTP id g12-v6so17334751lfb.10; Tue, 01 May 2018 11:22:27 -0700 (PDT) X-Gm-Message-State: ALQs6tAq7evczB7rbk8I3K+BL8oCUTPp/1CCVSJn+UnhSxF5B0EZk/75 AjCXdz223OpcMQEFrYV8FQE0400hsF+StgAUVgk= X-Google-Smtp-Source: AB8JxZp+nHgFCShNErVpna8EwBi8NR3o36XExwd5Bs+54NdFJGa8mQg0tsT4INpfhbydPrn3Av7r8G0GNisdITJvSJ8= X-Received: by 2002:a2e:8794:: with SMTP id n20-v6mr11775211lji.38.1525198945943; Tue, 01 May 2018 11:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Tue, 1 May 2018 11:22:05 -0700 (PDT) In-Reply-To: References: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> From: Kyle Evans Date: Tue, 1 May 2018 13:22:05 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Bug 207069 (loader password kills boot) To: Warner Losh Cc: David Cross , FreeBSD Hackers , Devin Teske Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:22:28 -0000 On Tue, May 1, 2018 at 1:17 PM, Warner Losh wrote: > > > On Tue, May 1, 2018 at 12:12 PM, Kyle Evans wrote: >> >> On Tue, May 1, 2018 at 1:07 PM, David Cross wrote: >> > The aforementioned bug has been open for over 2 years, with attached and >> > tested patches. At least one other has commented. >> > >> > Could we please have it for 11.2/12.0? >> >> Hi, >> >> CC'ing Devin, our local Forth-fu-fighter. If it looks ok to Devin, one >> of us should go ahead and shuffle this through. > > > Yes. I've looked at this code a fair amount, and I don't understand why this > is needed and why it would make things work. Since it is a security thing, > I'm very reluctant to push it in absent better understanding of why it > works. > Right, it also confuses me. =) When I was implementing this stuff for Lua, autoboot DTRT as long as module_path is setup correctly -- this is probably the part that's missing since IIRC that's usually done in menu setup (that doesn't happen here). I'm not sure if this the right way to fix it in Forth-land, though. From owner-freebsd-hackers@freebsd.org Tue May 1 18:49:40 2018 Return-Path: Delivered-To: freebsd-hackers@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 E5FC3FB3CAF for ; Tue, 1 May 2018 18:49:39 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79B4A6DFCE; Tue, 1 May 2018 18:49:39 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id p124-v6so14700061iod.1; Tue, 01 May 2018 11:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NF6xg0+dlnLN1hhMhO3rlh/h6QrW/a1tuZSwUeVyi+Y=; b=sLLwV3cTEpA3XQXSmODBphFJOnUFOOuI0cuoQIY3eHsmzhIt3qEPdBnk/7qHnZRmI5 yDrsJ6HDrYcTE+zkDml+jdz4VOICHITDzA/ijys5mcpcTu2QzuS2WH6t0hSljHMa/eFf VnDJ5Iyl+cvxEIMccPzTC9E3mFnH+MgukEIHDUGOQKUqYf4rrGhKzBpAz7/1AObkY8eO CCgZVyvLemkWcrDj5aNDiBil8LrlNyjDyLTCMxmgVGlN6DNG4x4jXfx4Mw81zLSgb7VM gInLh+j+xLVS5d8vhsFW76yapzcANXWHRqSjvQRiP9nvqF8uchXUMuytQfkZlsVb03eX 8KxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NF6xg0+dlnLN1hhMhO3rlh/h6QrW/a1tuZSwUeVyi+Y=; b=JsI1ACFQuuzLPNd7kUCUz3RjHk1jBY0RwMREnlSObBaZj4RlZ/Bu5ZYXNydiIezQzE 3+HCVzdKSJE42ljraZdg9eyx3eny6z8uTG9Po0Gza1gzXkaHkCPQATMx0+ilNE/McReL xPj+HLcIFqFcFPbTo+p3WmagT3uJDojxpNocB9pGyXg+mcFxP0xyNcpa5SkDhEd6Q5Ij qsZM7jZe4MTH7eDYy6IOCpC4iOMNYbKiJv5lYtqa6T8+FnYgRB3mnq47D7oMwu5h0Ok6 o67JaWsjuLrmKx4xP/NMFvZF1Vseo71+vR0TF3Zx9ocI4OhJdEEdfYDVm/1ZAB9qfsy+ MFHQ== X-Gm-Message-State: ALQs6tCRuxZg5GPoC5H5n8KId35JGmtEH/nZA6kWAOj6uaxbaUQYl0fz 6P5/cwKS7jh9AKbhWrB0TytraA== X-Google-Smtp-Source: AB8JxZqfajVh9NnhVErki2l9UCMtFEKKnsj6lzMZuRcMy0ZeFmPrw1hpSWoGNdErn8wRkjQvMWKiQg== X-Received: by 2002:a6b:86a7:: with SMTP id q39-v6mr17657053ioi.140.1525200578772; Tue, 01 May 2018 11:49:38 -0700 (PDT) Received: from [10.6.160.144] (rrcs-24-97-15-18.nys.biz.rr.com. [24.97.15.18]) by smtp.gmail.com with ESMTPSA id m14-v6sm4789097iti.1.2018.05.01.11.49.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 11:49:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Bug 207069 (loader password kills boot) From: David Cross X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Tue, 1 May 2018 14:49:36 -0400 Cc: Warner Losh , FreeBSD Hackers , Devin Teske Content-Transfer-Encoding: quoted-printable Message-Id: References: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> To: Kyle Evans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:49:40 -0000 =46rom my investigation when I wrote the patch originally the problem is (as= I recall, its been awhile) the forth dictionary space is limited so parts a= re flushed out (that is the only section at the top) additional dictionarie= s are then explicitly loaded (the also sections. The load_kernel and load_mo= dules are needed from the support-functions dictionaries As for why this is now needed here, there was a change made ~2 years ago to d= efer loading the kernel until the system was just about to boot (after beast= ie menu vs before). Autoboot assumes that kernel is loaded and will not load= for you. Making it load for you conflicts with the menu loading it. So it p= assword is enabled menu and kernel loading doesn=E2=80=99t happen. This reat= ores that and puts it right before autoboot (which is a C portion of loader)= (Going off of memory from ~2 years ago) Apologies for naming the patch works for me. This wasn=E2=80=99t just slap i= t in where it worked, i spent a good amount of time digging into what change= d, why, and to maintain the desired flow, > On May 1, 2018, at 14:22, Kyle Evans wrote: >=20 >> On Tue, May 1, 2018 at 1:17 PM, Warner Losh wrote: >>=20 >>=20 >>> On Tue, May 1, 2018 at 12:12 PM, Kyle Evans wrote: >>>=20 >>>> On Tue, May 1, 2018 at 1:07 PM, David Cross wrot= e: >>>> The aforementioned bug has been open for over 2 years, with attached an= d >>>> tested patches. At least one other has commented. >>>>=20 >>>> Could we please have it for 11.2/12.0? >>>=20 >>> Hi, >>>=20 >>> CC'ing Devin, our local Forth-fu-fighter. If it looks ok to Devin, one >>> of us should go ahead and shuffle this through. >>=20 >>=20 >> Yes. I've looked at this code a fair amount, and I don't understand why t= his >> is needed and why it would make things work. Since it is a security thing= , >> I'm very reluctant to push it in absent better understanding of why it >> works. >>=20 >=20 > Right, it also confuses me. =3D) >=20 > When I was implementing this stuff for Lua, autoboot DTRT as long as > module_path is setup correctly -- this is probably the part that's > missing since IIRC that's usually done in menu setup (that doesn't > happen here). >=20 > I'm not sure if this the right way to fix it in Forth-land, though. From owner-freebsd-hackers@freebsd.org Tue May 1 18:53:34 2018 Return-Path: Delivered-To: freebsd-hackers@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 E34D3FB4141 for ; Tue, 1 May 2018 18:53:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 745C66E700 for ; Tue, 1 May 2018 18:53:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id 70-v6so8305279ity.2 for ; Tue, 01 May 2018 11:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gXjmjPwnVr1iyzdy5c/jXg6f4ql0eMPeZypZHs9aqCw=; b=iQzsetUKB8Azm63hrvyX9JnbKM9bgnQjXWuAQqmcP4u2g6dRSRM1mcGGv5BHJCMzm1 9b0bXsGvj7xbJsxiTlUnqEqYVKrfSXPhl3xBB9ja9IHmLOZD1ropqbuXAEHchH5mteoA jbOkCVxPE16Nw2d/tKKWn7uLLppptvZuQf8odHiRmx2Zv2t4ICOGgeqFFnkVUT4kBXsk 7X9OaKb2sQ9hHXCJQnzmSp3n2GuP2OiUlZkjy16cJtDC5nGUL/kuura9piizy/bLn9DM 25ksKwixEI3SvWoVy3fXXciOi+qzjisf6NzcBeq+9T7q50ajk8+QD4XLoUVfeL/8Hoc4 2S9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gXjmjPwnVr1iyzdy5c/jXg6f4ql0eMPeZypZHs9aqCw=; b=bCVwzMtY8mQc5wY0GT7O7HCCybJRThR5MjBk1j8EEsYAtuqWj7LA5JMyMp+mg7+l7A kOC14yxBX+GzWY6g9N0gaoz0KlV4xhXeZ/DFS4BuNzMI2GI7wD05hB2zPr5SMTtnXA6B PItBTHzsC+TY3W2VwfqqfRaN7lvWOE6EVmBtGVF6UzuFBlm9madGYDznUHsngBG6uUOi PUnqsNUm1Bke3hFqvXuDmiyV3TNP6pY8Xo+8sT08EQtJISouwdY1CqMYQr7fB+G+To5d JvAvZRmbYar1w45WqIDzTgXssqxkp+vMWSvFAG+XkwpclSZUXTFWsuVUxqe4dOWlCKUL DlHA== X-Gm-Message-State: ALQs6tDLZi+6mbTlLQ+mynfZa+6qoO+w0piEKI4PzjewjG6Rf4ZvAnuc AgOReRXc8Wnc7FgEz7DzFCDpENgDrz+LYH1xmpzgDA== X-Google-Smtp-Source: AB8JxZo1wluO+NchhE8WODoKa9scQMF2fW1uJADYMcwQ5sXDWqTYekTUx5Mf40R61Vulavua3jG9Iy+q5Hb2wgI9Yds= X-Received: by 2002:a24:4c55:: with SMTP id a82-v6mr11882186itb.1.1525200812727; Tue, 01 May 2018 11:53:32 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Tue, 1 May 2018 11:53:32 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <7630266D-D078-41B3-BC27-32EBF65540C4@gmail.com> From: Warner Losh Date: Tue, 1 May 2018 12:53:32 -0600 X-Google-Sender-Auth: edf8uU_3gs8EYOMKcvudLxmoKGg Message-ID: Subject: Re: Bug 207069 (loader password kills boot) To: David Cross Cc: Kyle Evans , FreeBSD Hackers , Devin Teske Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:53:34 -0000 On Tue, May 1, 2018 at 12:49 PM, David Cross wrote: > From my investigation when I wrote the patch originally the problem is (a= s > I recall, its been awhile) the forth dictionary space is limited so parts > are flushed out (that is the only section at the top) additional > dictionaries are then explicitly loaded (the also sections. The load_kern= el > and load_modules are needed from the support-functions dictionaries > That matches my reading of the also clause. Thanks. > As for why this is now needed here, there was a change made ~2 years ago > to defer loading the kernel until the system was just about to boot (afte= r > beastie menu vs before). Autoboot assumes that kernel is loaded and will > not load for you. Making it load for you conflicts with the menu loading > it. So it password is enabled menu and kernel loading doesn=E2=80=99t hap= pen. This > reatores that and puts it right before autoboot (which is a C portion of > loader) > OK. That gives me something to go on to look at things more closely. > (Going off of memory from ~2 years ago) > > Apologies for naming the patch works for me. This wasn=E2=80=99t just sla= p it in > where it worked, i spent a good amount of time digging into what changed, > why, and to maintain the desired flow, OK. That also helps. Thanks for taking the time to dust off the memories. Warner > > On May 1, 2018, at 14:22, Kyle Evans wrote: > > > >> On Tue, May 1, 2018 at 1:17 PM, Warner Losh wrote: > >> > >> > >>> On Tue, May 1, 2018 at 12:12 PM, Kyle Evans > wrote: > >>> > >>>> On Tue, May 1, 2018 at 1:07 PM, David Cross > wrote: > >>>> The aforementioned bug has been open for over 2 years, with attached > and > >>>> tested patches. At least one other has commented. > >>>> > >>>> Could we please have it for 11.2/12.0? > >>> > >>> Hi, > >>> > >>> CC'ing Devin, our local Forth-fu-fighter. If it looks ok to Devin, on= e > >>> of us should go ahead and shuffle this through. > >> > >> > >> Yes. I've looked at this code a fair amount, and I don't understand wh= y > this > >> is needed and why it would make things work. Since it is a security > thing, > >> I'm very reluctant to push it in absent better understanding of why it > >> works. > >> > > > > Right, it also confuses me. =3D) > > > > When I was implementing this stuff for Lua, autoboot DTRT as long as > > module_path is setup correctly -- this is probably the part that's > > missing since IIRC that's usually done in menu setup (that doesn't > > happen here). > > > > I'm not sure if this the right way to fix it in Forth-land, though. > From owner-freebsd-hackers@freebsd.org Tue May 1 19:22:22 2018 Return-Path: Delivered-To: freebsd-hackers@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 9D4FFFB5117 for ; Tue, 1 May 2018 19:22:22 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2167676F95; Tue, 1 May 2018 19:22:22 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pf0-x22d.google.com with SMTP id q22so9754408pff.11; Tue, 01 May 2018 12:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0KtgPPJ9/Zpl41414O6vXAFvoWYraUwFNrI1YrSH04k=; b=RoNN9T9sTmIq5Naj7VdMwhDYvpegfHKnkAEvI1Ov5pe+kRN97LJ66owUj7smkMJxqm MG0wB0kYqyUvO6fQhjB7fbfRtN8U9HUuSZvlfEjllx4LWyliLShWZzzTVLixXZ6/Lhla majInnvLUcdXZwGYcZkG2x6L+CMmOQQGc9+zt7Gk8TLK8zz9+DIsqLCofggumk1/t+fe kBJwauRLts7l3RxI3AEtw7cgfupVRPva70JfKxRLXNzCJ9POoACtjerNiK7/3k1Nmdog t61STuU+uOhKI2cTspuvRx37mhcAo23IKkG7AG0HN3vWrSn15q5w212hl3FIPD/TuWW4 x2/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0KtgPPJ9/Zpl41414O6vXAFvoWYraUwFNrI1YrSH04k=; b=TVg4bUuOoCod7K/qn9QTLg+1qNnF3q91k/qs5qC1YjZn+Q4x9j0S0paIH1WbVm6P+9 z+UDtOyvSfjmih/LQshqh1J3dUVg3+BMbopfDTSfMt/8NRrOMzoljCs+T+U+Xfempb6l 47lUcUxp0SJM40voWBaY0c4md1oQ2VvvWsD4HVxq5JlLGpiBJqPgtX0EWYZYN8CAnDGL 8ydr6zYb40AKe2mKz7oCFqjpT9bepfrHwWRMcv9PTW3TPJLyW5NsXpmcP+OKOPyFFH5l nwQwV5cUhVOjS/hu4vNlMXBbNc5mHkID7DDMojHz/xKS9UpwYmL7ESgWZ8rlxyhbSjQp r4Ag== X-Gm-Message-State: ALQs6tCpXkAFlZZ08a0pCU2Z0pfSFVSkzzu+T4rCtTMBOuJMWyHv2Sd7 uONx4LifM/7Eeofp7KdXP7tM+iwNQYFkT3VRfcWIKA== X-Google-Smtp-Source: AB8JxZqsGS5Yi2Fn4WhBUlLcsqE75S/l+XPQuJ/V2h7Vw56d/XOf3na/JyfwBF8Sp1UuZnFik5fRZdvVcp9UDuxjtMI= X-Received: by 2002:a17:902:6505:: with SMTP id b5-v6mr17257028plk.147.1525202540919; Tue, 01 May 2018 12:22:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.201 with HTTP; Tue, 1 May 2018 12:21:50 -0700 (PDT) In-Reply-To: References: From: Gleb Popov <6yearold@gmail.com> Date: Tue, 1 May 2018 22:21:50 +0300 Message-ID: Subject: Re: Porting questions To: Craig Leres Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 19:22:22 -0000 On Tue, May 1, 2018 at 8:26 PM, Craig Leres wrote: > I'm working a port for the Espressif ESP32 toolchain so I can move > development of some projects (FreeRTOS and Arduino) from Ubuntu to FreeBSD. > I have a few questions. > > (1) Naming: The pre-built linux 64 bit toolchain is called: > > xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz > > so I thought the port should be called xtensa-esp32-elf; is this a > reasonable name? > > (2) Port version: The toolchain is built from the latest version: > > https://github.com/espressif/crosstool-NG > > There is not a release that corresponds to this version; is it legit for > me to use: > > DISTVERSION= 1.22.0-80-g6c4433a5 > GH_TUPLE= espressif:crosstool-NG:${DISTVERSION} > > which apparently gives me 1.22.0.80.g6.c4433.a5 as the PORTVERSION? > > (3) USES=gcc doesn't provide a binary named gcc: crosstool-NG has the > string "gcc" firmly baked into it. When I have USES=gcc (today) I get gcc6 > but without patching a ton of files I need gcc to exist when poudriere is > building. I solved this by also adding: > > BUILD_DEPENDS+= gcc:lang/gcc > > but it seems wrong to me that USES=gcc doesn't provide a binary named gcc. > You can add BINARY_ALIAS= gcc=gcc6 line to work around this. > (4) How to handle downloads that shouldn't be extracted: The toolchain > uses specific versions of a bunch of things: > > TARBALLS= \ > binutils-2.25.1.tar.bz2 \ > expat-2.1.0.tar.gz \ > gcc-5.2.0.tar.bz2 \ > gdb-7.10.tar.xz \ > gmp-6.0.0a.tar.xz \ > isl-0.14.tar.xz \ > mpc-1.0.3.tar.gz \ > mpfr-3.1.3.tar.xz \ > ncurses-6.0.tar.gz \ > newlib-2.2.0.tar.gz > > Normally the build process downloads these which doesn't work well with > poudriere; you don't want to download these every time you build port. I > put copies in my /usr/ports/distfiles and add symlinks to the work tree in > post-extract and later the build script correctly skips downloading them > when it finds them already there. I'd like to add these to DISTFILES for > auto-download and checksums but I don't want them extracted by do-extract. > Is my best option to override the do-extract target? > > I've attached the current version of the Makefile for informal review. > > Craig > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Tue May 1 20:10:40 2018 Return-Path: Delivered-To: freebsd-hackers@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 0FA72FB6DBC for ; Tue, 1 May 2018 20:10:40 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (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 9F28B8585D for ; Tue, 1 May 2018 20:10:39 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 4913D3B92C; Tue, 1 May 2018 22:10:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns44EQSgsB9Z; Tue, 1 May 2018 22:10:31 +0200 (CEST) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id ABB533B92B; Tue, 1 May 2018 22:10:31 +0200 (CEST) Subject: Re: Getting pthread names To: =?UTF-8?Q?Manuel_St=c3=bchn?= Cc: freebsd-hackers@freebsd.org References: <20180430111434.GA18085@freebsd-t450.fritz.box> <20180430135711.GT6887@kib.kiev.ua> <20180430192506.GA86258@freebsd-t450.fritz.box> From: Willem Jan Withagen Message-ID: <5504160e-f3d9-db64-c851-fd829b28c04c@digiware.nl> Date: Tue, 1 May 2018 22:10:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180430192506.GA86258@freebsd-t450.fritz.box> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 20:10:40 -0000 On 30/04/2018 21:25, Manuel Stühn wrote: > On Mon, Apr 30, 2018 at 04:57:11PM +0300, Konstantin Belousov wrote: >> On Mon, Apr 30, 2018 at 01:14:34PM +0200, Manuel St?hn wrote: >>> Hi, >>> >>> for setting a name for pthreads i found pthread_set_name_np(3), but for >>> retrieving the name i found nothing. Is there any api like >>> pthread_getname_np for FreeBSD? Or is there another way to retrieve the >>> threads name within an application? >> >> Not like pthread_getname_np(), but still something.  You can use >> (binary) sysctl kern.proc.pid. to get struct kinfo_proc for all >> threads.  In the structure, the ki_tdname() member contains the thread >> name as set by pthread_set_name_np(3). > > Thank you (all) for your answer(s) and hints! I'll have a look into this. I asked the same question some time ago, because Ceph also uses this in all kinds of analysis. It is/was still on my todo list, but since it is only informational, it is not high on priority. But would be more than interested to test/use an implementation. --WjW From owner-freebsd-hackers@freebsd.org Tue May 1 21:25:44 2018 Return-Path: Delivered-To: freebsd-hackers@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 A3225FB86B9; Tue, 1 May 2018 21:25:44 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (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 3708F7647D; Tue, 1 May 2018 21:25:43 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 988833D726; Tue, 1 May 2018 23:25:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCSJBzm6VGGg; Tue, 1 May 2018 23:25:41 +0200 (CEST) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 3B85E3D720; Tue, 1 May 2018 23:25:40 +0200 (CEST) Subject: Re: Getting ZFS pools back. From: Willem Jan Withagen To: Warner Losh , Jan Knepper Cc: FreeBSD Filesystems , FreeBSD Hackers , Richard Yao , Alan Somers References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> <7588abf8-16e4-8820-a0e5-e019a02a7bd6@digiware.nl> Message-ID: Date: Tue, 1 May 2018 23:25:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 21:25:44 -0000 On 30/04/2018 12:37, Willem Jan Withagen wrote: > On 29-4-2018 23:20, Willem Jan Withagen wrote: >> On 29/04/2018 20:21, Warner Losh wrote: >>> >>> >>> On Sun, Apr 29, 2018 at 11:57 AM, Jan Knepper >> > wrote: >>> >>>     On 04/29/2018 13:27, Willem Jan Withagen wrote: >>> >>>         Trouble started when I installed (freebsd-update) 11.1 over a >>>         running 10.4. Which is sort of scarry? >>> >>>     This does sounds 'scary' as I am planning to do this in the (near) >>>     future... >>> >>>     Has anyone else experienced issues like this? >>> >>>     Generally I do build the new system software on a running system, >>>     but then go to single user mode to perform the actual install. >>> >>>     I have done many upgrades like that over 18 or so years and never >>>     seen or heard of an issue alike this. >>> >>> >>> 11.x binaries aren't guaranteed to work with a 10.x kernel. So that's >>> a bit of a problem. freebsd-update shouldn't have let you do that >>> either. >>> >>> However, most 11.x binaries work well enough to at least bootstrap / >>> fix problems if booted on a 10.x kernel due to targeted forward >>> compatibility. You shouldn't count on it for long, but it generally >>> won't totally brick your box. In the past, and I believe this is >>> still true, they work well enough to compile and install a new kernel >>> after pulling sources. The 10.x -> 11.x syscall changes are such that >>> you should be fine. At least if you are on UFS. >> >> I have been doing those kind of this for years and years. Even >> upgrading over NFS and stuff. Sometimes it is a bit too close to the >> sun and things burn. But never crash this bad. >> >>> However, the ZFS ioctls and such are in the bag of 'don't >>> specifically guarantee and also they change a lot' so that may be why >>> you can't mount ZFS by UUID. I've not checked to see if there's >>> specifically an issue here or not. The ZFS ABI is somewhat more >>> fragile than other parts of the system, so you may have issues here. >>> >>> If all else fails, you may be able to PXE boot an 11 kernel, or boot >>> off a USB memstick image to install a kernel. >> >> Tried just about replace everything in both the boot-partition (First >> growing it to take > 64K gptzfsboot) and in /boot from the memstick. >> But the error never went away. >> >> Never had ZFS die on me this bad, that I could not get it back. >> >>> Generally, while we don't guarantee forward compatibility (running >>> newer binaries on older kernels), we've generally built enough >>> forward compat so that things work well enough to complete the >>> upgrade. That's why you haven't hit an issue in 18 years of >>> upgrading. However, the velocity of syscall additions has increased, >>> and we've gone from fairly stable (stale?) ABIs for UFS to a more >>> dynamic one for ZFS where backwards compat is a bit of a crap shoot >>> and forward compat isn't really there at all. That's likely why >>> you've hit a speed bump here. >> >> Come to think of it, I did not do this step with freebsd-update, since >> I was not at an official release yet. I was going to 11.1-RELEASE, to >> be able to start using freebsd-update. >> >> So I don't think I did just do that.... But I tried so much yesterday. >> Normally I would installkernel, reboot, installworld, mergemaster, >> reboot for systems that are not up for freebsd-update. > > Right, > > The story gets even sadder ..... > Took the "spare" disk home, and just connected it to an older SuperMicro > server I had lying about for Ceph tests. And lo and behold, it just boots. > > So that system got upgraded from: 10.2 -> 10.4 -> 11.1 > No complaints about anything. > > So now I'm inclined to point at older hardware with an old bios, which > confused ZFS, or probably more precisely gptzfsboot. > > From dmidecode: > System Information >         Manufacturer: Supermicro >         Product Name: H8SGL >         Version: 1234567890 > BIOS Information >         Vendor: American Megatrends Inc. >         Version: 3.5 >         Release Date: 11/25/2013 >         Address: 0xF0000 > > We only have 1 of those, so further investigation, and or tinkering, in > combo with the hardware will be impossible. Today i found the messages below in my daily report of the server: +NMI ISA 3c, EISA ff +NMI ISA 3c, EISA ff +NMI ISA 3c, EISA ff +NMI ... going to debugger +NMI ... going to debugger +NMI ISA 3c, EISA ff +NMI ISA 2c, EISA ff +NMI ... going to debugger +NMI ... going to debugger +NMI ISA 2c, EISA ff +NMI ISA 3c, EISA ff +NMI ... going to debugger +NMI ... going to debugger +NMI ... going to debugger +NMI ISA 3c, EISA ff +NMI ... going to debugger Could these things have anything to do with the problem I had with trying to find the pools. --WjW From owner-freebsd-hackers@freebsd.org Wed May 2 02:29:13 2018 Return-Path: Delivered-To: freebsd-hackers@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 E6DB4FBEF8A for ; Wed, 2 May 2018 02:29:12 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84539742DE for ; Wed, 2 May 2018 02:29:12 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2620:83:8000:102::cb; helo=hot.ee.lbl.gov; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from hot.ee.lbl.gov (hot.ee.lbl.gov [IPv6:2620:83:8000:102:0:0:0:cb]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w422T6cn077039 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 1 May 2018 19:29:09 -0700 (PDT) (envelope-from leres@freebsd.org) Subject: Re: Porting questions To: =?UTF-8?Q?Le_Baron_d=e2=80=99Merde?= , Gleb Popov <6yearold@gmail.com>, freebsd-hackers@freebsd.org References: <20180501180402.e4kigr4f5qh44m6d@privacychain.ch> From: Craig Leres Message-ID: <9d9f4709-99c4-74fb-0ff7-f0381172fd20@freebsd.org> Date: Tue, 1 May 2018 19:29:05 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180501180402.e4kigr4f5qh44m6d@privacychain.ch> Content-Type: multipart/mixed; boundary="------------14DB82093F49C383061B88EC" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.0 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-11394-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 02:29:13 -0000 This is a multi-part message in MIME format. --------------14DB82093F49C383061B88EC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 05/01/18 11:04, Le Baron d’Merde wrote: > When upstream does not provide a version (or a separated commit will be used > like HEAD), the version format to be used for GitHub is: gYYYYMMDD > > See 5.13: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description I missed that; it's perfect, thanks! >> (4) How to handle downloads that shouldn't be extracted: The toolchain uses >> specific versions of a bunch of things: >> >> TARBALLS= \ >> binutils-2.25.1.tar.bz2 \ >> expat-2.1.0.tar.gz \ >> gcc-5.2.0.tar.bz2 \ >> gdb-7.10.tar.xz \ >> gmp-6.0.0a.tar.xz \ >> isl-0.14.tar.xz \ >> mpc-1.0.3.tar.gz \ >> mpfr-3.1.3.tar.xz \ >> ncurses-6.0.tar.gz \ >> newlib-2.2.0.tar.gz >> >> Normally the build process downloads these which doesn't work well with >> poudriere; you don't want to download these every time you build port. I put >> copies in my /usr/ports/distfiles and add symlinks to the work tree in >> post-extract and later the build script correctly skips downloading them >> when it finds them already there. I'd like to add these to DISTFILES for >> auto-download and checksums but I don't want them extracted by do-extract. >> Is my best option to override the do-extract target? > > I guess those are git submodules. GH_TUPLE are used for them. You can see a > working example on x11/polybar Actually they're not, they're just the specific versions of things that are built to deal with the cross compile objects. In the end I added them to DISTFILES with the appropriate MASTER_SITES entries and discovered EXTRACT_ONLY and set that to the github tarball. On 05/01/18 12:21, Gleb Popov wrote: > (3) USES=gcc doesn't provide a binary named gcc: crosstool-NG has > the string "gcc" firmly baked into it. When I have USES=gcc (today) > I get gcc6 but without patching a ton of files I need gcc to exist > when poudriere is building. I solved this by also adding: > > BUILD_DEPENDS+= gcc:lang/gcc > > but it seems wrong to me that USES=gcc doesn't provide a binary > named gcc. > > > You can add > BINARY_ALIAS= gcc=gcc6 > line to work around this. It'd be sweet if this worked but it doesn't. I think the problem is that create-binary-alias happens slightly before do-configure which is the first place I need gcc to exist. Thanks guys! Craig --------------14DB82093F49C383061B88EC Content-Type: text/plain; charset=UTF-8; name="Makefile" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Makefile" IyBDcmVhdGVkIGJ5OiBDcmFpZyBMZXJlcyA8bGVyZXNAZnJlZWJzZC5vcmc+CiMgJEZyZWVC U0QkCgpQT1JUTkFNRT0JeHRlbnNhLWVzcDMyLWVsZgpESVNUVkVSU0lPTj0JMS4yMi4wLmcy MDE3MTIxOQpDQVRFR09SSUVTPQlkZXZlbApNQVNURVJfU0lURVM9CUdOVS9iaW51dGlsczpz b3VyY2UxIFwKCQlodHRwczovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9leHBhdC9maWxl cy9leHBhdC8yLjEuMC86c291cmNlMiBcCgkJR05VL2djYy9nY2MtNS4yLjAvOnNvdXJjZTMg XAoJCUdOVS9nZGI6c291cmNlNCBcCgkJR05VL2dtcDpzb3VyY2U1IFwKCQlodHRwOi8vaXNs Lmdmb3JnZS5pbnJpYS5mci86c291cmNlNiBcCgkJR05VL21wYzpzb3VyY2U3IFwKCQlodHRw Oi8vd3d3Lm1wZnIub3JnL21wZnItMy4xLjMvOnNvdXJjZTggXAoJCUdOVS9uY3Vyc2VzOnNv dXJjZTkgXAoJCWh0dHBzOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL2RldmtpdHByby9m aWxlcy9zb3VyY2VzL25ld2xpYi86c291cmNlMTAKRElTVEZJTEVTPQliaW51dGlscy0yLjI1 LjEudGFyLmJ6Mjpzb3VyY2UxIFwKCQlleHBhdC0yLjEuMC50YXIuZ3o6c291cmNlMiBcCgkJ Z2NjLTUuMi4wLnRhci5iejI6c291cmNlMyBcCgkJZ2RiLTcuMTAudGFyLnh6OnNvdXJjZTQg XAoJCWdtcC02LjAuMGEudGFyLnh6OnNvdXJjZTUgXAoJCWlzbC0wLjE0LnRhci54ejpzb3Vy Y2U2IFwKCQltcGMtMS4wLjMudGFyLmd6OnNvdXJjZTcgXAoJCW1wZnItMy4xLjMudGFyLnh6 OnNvdXJjZTggXAoJCW5jdXJzZXMtNi4wLnRhci5nejpzb3VyY2U5IFwKCQluZXdsaWItMi4y LjAudGFyLmd6OnNvdXJjZTEwCkVYVFJBQ1RfT05MWT0JJHtESVNUTkFNRX0ke0VYVFJBQ1Rf U1VGWH0KCk1BSU5UQUlORVI9CWxlcmVzQGZyZWVic2Qub3JnCkNPTU1FTlQ9CVRvb2xjaGFp biBmb3IgeHRlbnNhLWVzcDMyLWVsZgoKTElDRU5TRT0JR1BMdjIgTEdQTDIxCkxJQ0VOU0Vf Q09NQj0JbXVsdGkKCkJVSUxEX0RFUEVORFMrPQliYXNoOnNoZWxscy9iYXNoIFwKCQlnYXdr OmxhbmcvZ2F3ayBcCgkJZ2NjOmxhbmcvZ2NjIFwKCQlnaXQ6ZGV2ZWwvZ2l0IFwKCQlncGF0 Y2g6ZGV2ZWwvcGF0Y2ggXAoJCSR7TE9DQUxCQVNFfS9iaW4vZ3JlcDp0ZXh0cHJvYy9nbnVn cmVwIFwKCQlncGVyZjpkZXZlbC9ncGVyZiBcCgkJZ3NlZDp0ZXh0cHJvYy9nc2VkIFwKCQlo ZWxwMm1hbjptaXNjL2hlbHAybWFuIFwKCQltYWtlaW5mbzpwcmludC90ZXhpbmZvIFwKCQlw eXRob246bGFuZy9weXRob24gXAoJCXdnZXQ6ZnRwL3dnZXQKClVTRVM9CQlhdXRvcmVjb25m OmJ1aWxkIGJpc29uIGdtYWtlIGxpYnRvb2wgcHl0aG9uOmJ1aWxkClVTRV9HQ0M9CXllcwpV U0VfR0lUSFVCPQl5ZXMKVVNFX0xEQ09ORklHPQkke1BSRUZJWH0vJHtQT1JUTkFNRX0vbGli ZXhlYy9nY2MveHRlbnNhLWVzcDMyLWVsZi81LjIuMApTVUJESVI9CQljcm9zc3Rvb2wtTkcK VEFHTkFNRT0JMS4yMi4wLTgwLWc2YzQ0MzNhNQpHSF9UVVBMRT0JZXNwcmVzc2lmOiR7U1VC RElSfToke1RBR05BTUV9Cgpwb3N0LWV4dHJhY3Q6Cgkke01LRElSfSAke0JVSUxEX1dSS1NS Q30vLmJ1aWxkL3RhcmJhbGxzCi5mb3IgRiBpbiAkKERJU1RGSUxFUzpOJChFWFRSQUNUX09O TFkpKQoJJHtMTn0gLXMgJHtESVNURElSfS8ke0Y6Qy86c291cmNlWzAtOV0rJC8vfSAke0JV SUxEX1dSS1NSQ30vLmJ1aWxkL3RhcmJhbGxzCi5lbmRmb3IKCnByZS1jb25maWd1cmU6Cgkg Y2QgJHtCVUlMRF9XUktTUkN9ICYmIC4vYm9vdHN0cmFwCgkgJHtQUklOVEZ9ICIjIS9iaW4v c2hcbmVjaG8gJyR7U1VCRElSOnRsfS0ke1RBR05BTUV9J1xuIiA+IFwKCSAgICAgJHtCVUlM RF9XUktTUkN9L3ZlcnNpb24uc2gKCSAke0NITU9EfSAtdyt4ICR7QlVJTERfV1JLU1JDfS92 ZXJzaW9uLnNoCgpkby1jb25maWd1cmU6CgljZCAke0JVSUxEX1dSS1NSQ30gJiYgXAoJICAg IC4vY29uZmlndXJlIC0tZW5hYmxlLWxvY2FsIC0td2l0aC1ncmVwPSR7TE9DQUxCQVNFfS9i aW4vZ3JlcAoKcHJlLWJ1aWxkOgoJY2QgJHtCVUlMRF9XUktTUkN9ICYmIFwKCSAgICAke1NF VEVOVn0gLXVNQUtFTEVWRUwgLXVNQUtFRkxBR1MgLXUuTUFLRS5MRVZFTC5FTlYgXAoJICAg ICR7TUFLRV9DTUR9IGluc3RhbGwgJiYgLi9jdC1uZyB4dGVuc2EtZXNwMzItZWxmCgpkby1i dWlsZDoKCWNkICR7QlVJTERfV1JLU1JDfSAmJiBDVF9BTExPV19CVUlMRF9BU19ST09UX1NV UkU9MSAuL2N0LW5nIGJ1aWxkCgpwb3N0LWJ1aWxkOgoJY2QgJHtCVUlMRF9XUktTUkN9L2J1 aWxkcy8ke1BPUlROQU1FfSAmJiBcCgkgICAgJHtSTX0gYnVpbGQubG9nLmJ6MiBsaWIvY2hh cnNldC5hbGlhcwoKZG8taW5zdGFsbDoKCWNkICR7QlVJTERfV1JLU1JDfS9idWlsZHMgJiYg XAoJICAgICR7Q09QWVRSRUVfU0hBUkV9ICR7UE9SVE5BTUV9ICR7U1RBR0VESVJ9JHtQUkVG SVh9CgouaW5jbHVkZSA8YnNkLnBvcnQubWs+Cg== --------------14DB82093F49C383061B88EC-- From owner-freebsd-hackers@freebsd.org Wed May 2 02:39:09 2018 Return-Path: Delivered-To: freebsd-hackers@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 54227FBF4B0 for ; Wed, 2 May 2018 02:39:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E238C764FE; Wed, 2 May 2018 02:39:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-108-197.dyn.iinet.net.au [124.148.108.197]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w422d1sC008590 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 May 2018 19:39:05 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Getting pthread names To: Konstantin Belousov , Manuel St?hn Cc: freebsd-hackers@freebsd.org References: <20180430111434.GA18085@freebsd-t450.fritz.box> <20180430135711.GT6887@kib.kiev.ua> From: Julian Elischer Message-ID: <44e3f0c6-0397-404b-3fb9-a67e7f592024@freebsd.org> Date: Wed, 2 May 2018 10:38:55 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180430135711.GT6887@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 02:39:09 -0000 On 30/4/18 9:57 pm, Konstantin Belousov wrote: > On Mon, Apr 30, 2018 at 01:14:34PM +0200, Manuel St?hn wrote: >> Hi, >> >> for setting a name for pthreads i found pthread_set_name_np(3), but for >> retrieving the name i found nothing. Is there any api like >> pthread_getname_np for FreeBSD? Or is there another way to retrieve the >> threads name within an application? > Not like pthread_getname_np(), but still something. You can use > (binary) sysctl kern.proc.pid. to get struct kinfo_proc for all > threads. In the structure, the ki_tdname() member contains the thread > name as set by pthread_set_name_np(3). > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > and ps in the kernel debugger shows it as well from memory check top and ps in "show thread" mode.... at one stage I remember writing code to show thread names but I can't remember what programs it went into..  (around 2001), I suspect that you are expected to remember your own name. the name writing is so other processes can get that information. From owner-freebsd-hackers@freebsd.org Wed May 2 09:08:56 2018 Return-Path: Delivered-To: freebsd-hackers@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 7765EFC6D71 for ; Wed, 2 May 2018 09:08:56 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DEE57E21D; Wed, 2 May 2018 09:08:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from [10.0.0.52] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTPSA id w4293PXg042126 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 May 2018 05:03:25 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 02 May 2018 05:03:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Getting pthread names From: Daniel Eischen X-Mailer: iPhone Mail (15E302) In-Reply-To: <44e3f0c6-0397-404b-3fb9-a67e7f592024@freebsd.org> Date: Wed, 2 May 2018 05:03:25 -0400 Cc: Konstantin Belousov , Manuel St?hn , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180430111434.GA18085@freebsd-t450.fritz.box> <20180430135711.GT6887@kib.kiev.ua> <44e3f0c6-0397-404b-3fb9-a67e7f592024@freebsd.org> To: Julian Elischer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 09:08:56 -0000 > On May 1, 2018, at 10:38 PM, Julian Elischer wrote: >=20 >> On 30/4/18 9:57 pm, Konstantin Belousov wrote: >>> On Mon, Apr 30, 2018 at 01:14:34PM +0200, Manuel St?hn wrote: >>> Hi, >>>=20 >>> for setting a name for pthreads i found pthread_set_name_np(3), but for >>> retrieving the name i found nothing. Is there any api like >>> pthread_getname_np for FreeBSD? Or is there another way to retrieve the >>> threads name within an application? >> Not like pthread_getname_np(), but still something. You can use >> (binary) sysctl kern.proc.pid. to get struct kinfo_proc for all >> threads. In the structure, the ki_tdname() member contains the thread >> name as set by pthread_set_name_np(3). >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >>=20 > and ps in the kernel debugger shows it as well from memory >=20 > check top and ps in "show thread" mode.... at one stage I remember writing= code to show thread names >=20 > but I can't remember what programs it went into.. (around 2001), >=20 >=20 > I suspect that you are expected to remember your own name. the name writin= g is so other processes can get that information. I think I toyed with idea of adding pthread_set_name_np() back in the old li= bc_r days. I'm not sure why I didn't? The problem with remembering to what you set each thread's name, is that the names may be set by libraries o= r code out of your control. Maybe not a common use case, though. The set n= ame function is void return, so you can't even get the name to see if the se= tter actually worked. I think the libc_r version just did a strdup() of sor= ts, so it could be as long as necessary (bug or feature?). The current lim= it seems to be MAXCOMLEN, which is 19, and I think just silently fails if mo= re than that. -- DE= From owner-freebsd-hackers@freebsd.org Wed May 2 09:47:33 2018 Return-Path: Delivered-To: freebsd-hackers@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 297D2FC7C1C; Wed, 2 May 2018 09:47:33 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F6038648A; Wed, 2 May 2018 09:47:32 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f42.google.com with SMTP id g12-v6so19910813lfb.10; Wed, 02 May 2018 02:47: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:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0M1IFBvXCXyWKO3WUpYCih+fjR3mAQDZlmIXnTYmP7w=; b=CbNpbnO0HwDcvtgeTxuwCJ6nmRCculbe73sLBdr0pciiM9WgowAh+lhyc5FHecs/u3 lNGxcGdbmwhsONoGO0GfIPgMwvWcBygtjEGLJz3YTqMBKPT6ussFN0kZIcfwy4rOIyKX PqZM4VuVE/wxh/SL287+JM+46FE3veEWlOHWoDjWmVJeRKSm6TPUsKSLTf309oyVfUB6 owU3QxMU8F9SVSvt2S8+SKwLDsMFBXIfaLFu/uzFVtleEj2NjknMfhYJFYRUST+YhMp2 PhebaPHwp4/VFIgxsWVWgj09cZfrCD1ugDdiM068PQqXfOp7MVScPxms+wCNzcssRzxa /5Yg== X-Gm-Message-State: ALQs6tAT8A2j2tEkeCaMf2ZSuqJPYZNsou7yAtolh0AjuI1JDSLGMv3W QlL03QkIfMqHwcxTJulfKEvT/PmG X-Google-Smtp-Source: AB8JxZqYQ7cT6orIJhU8Iza78/Y5cjtWbxU6z3itxu/xmIollxCVhkrmKI5Qxsq9tFigM+m/zyPVXA== X-Received: by 2002:a2e:320b:: with SMTP id y11-v6mr12485388ljy.119.1525254444993; Wed, 02 May 2018 02:47:24 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id g20-v6sm2336902lfk.39.2018.05.02.02.47.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 02:47:24 -0700 (PDT) Subject: Re: Getting ZFS pools back. To: Willem Jan Withagen Cc: FreeBSD Filesystems , FreeBSD Hackers References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> <7588abf8-16e4-8820-a0e5-e019a02a7bd6@digiware.nl> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+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/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+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 HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM 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: <616ffef3-195b-47fa-fcc6-1ba9f5545bef@FreeBSD.org> Date: Wed, 2 May 2018 12:47:22 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 09:47:33 -0000 On 30/04/2018 13:37, Willem Jan Withagen wrote: > So now I'm inclined to point at older hardware with an old bios, which confused > ZFS, or probably more precisely gptzfsboot. I think that this alone wouldn't explain the problems you had with zpool import. Maybe you had multiple issues at the same time. - something with BIOS caused trouble with booting - something else, e.g. kernel-userland mismatch, caused zpool commands to misbehave -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed May 2 12:00:47 2018 Return-Path: Delivered-To: freebsd-hackers@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 D3304FA749E; Wed, 2 May 2018 12:00:47 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 6A5FF85DCB; Wed, 2 May 2018 12:00:47 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 465633DB6B; Wed, 2 May 2018 14:00:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v2x8m-JhTxk; Wed, 2 May 2018 14:00:44 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id AD01D3DB6A; Wed, 2 May 2018 14:00:44 +0200 (CEST) Subject: Re: Getting ZFS pools back. To: Andriy Gapon Cc: FreeBSD Filesystems , FreeBSD Hackers References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> <1645b168-4133-693c-2dd3-8e0606abb9c3@digiware.nl> <07576f68-f67e-3a22-7a50-ff261c9b3fff@digitaldaemon.com> <7588abf8-16e4-8820-a0e5-e019a02a7bd6@digiware.nl> <616ffef3-195b-47fa-fcc6-1ba9f5545bef@FreeBSD.org> From: Willem Jan Withagen Message-ID: <7c0b4478-ff87-0d70-d9ef-203122c2bc7f@digiware.nl> Date: Wed, 2 May 2018 14:00:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <616ffef3-195b-47fa-fcc6-1ba9f5545bef@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 12:00:48 -0000 On 2-5-2018 11:47, Andriy Gapon wrote: > On 30/04/2018 13:37, Willem Jan Withagen wrote: >> So now I'm inclined to point at older hardware with an old bios, which confused >> ZFS, or probably more precisely gptzfsboot. > > I think that this alone wouldn't explain the problems you had with zpool import. > Maybe you had multiple issues at the same time. > - something with BIOS caused trouble with booting > - something else, e.g. kernel-userland mismatch, caused zpool commands to misbehave More than likely you are right. Frustrating was, how ever, that most trouble I run into, I can fix. Doing FreeBSD for so long, makes that I don't easily give up. But after 4 hours of fiddling with bootsectors, loaders, setting and what not, I gave up. Also because I did not want to jeopardize the data. (It is on backup, but the backup was already 8 hours stale) But hey, system is backup. And haven't heart anybody complaining about missing data, of other failures.... --WjW From owner-freebsd-hackers@freebsd.org Wed May 2 14:23:59 2018 Return-Path: Delivered-To: freebsd-hackers@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 40AD8FAB3E8 for ; Wed, 2 May 2018 14:23:59 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id DBA8C84B89; Wed, 2 May 2018 14:23:58 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id AD7AC5646F; Wed, 2 May 2018 09:23:51 -0500 (CDT) Subject: Re: Getting pthread names To: Daniel Eischen , Julian Elischer Cc: freebsd-hackers@freebsd.org, Manuel St?hn , Konstantin Belousov References: <20180430111434.GA18085@freebsd-t450.fritz.box> <20180430135711.GT6887@kib.kiev.ua> <44e3f0c6-0397-404b-3fb9-a67e7f592024@freebsd.org> From: Eric van Gyzen Openpgp: preference=signencrypt Message-ID: <7f4690e8-ed2e-00b5-141f-c0d626ccab35@vangyzen.net> Date: Wed, 2 May 2018 09:23:47 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 14:23:59 -0000 On 05/02/2018 04:03, Daniel Eischen wrote: > The current limit seems to be MAXCOMLEN, which is 19, and I think > just silently fails if more than that. It used to silently fail, but now it silently truncates. https://svnweb.freebsd.org/base?view=revision&revision=309460 Eric From owner-freebsd-hackers@freebsd.org Thu May 3 01:59:48 2018 Return-Path: Delivered-To: freebsd-hackers@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 78E26FBBE98 for ; Thu, 3 May 2018 01:59:48 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id E10B7837D3 for ; Thu, 3 May 2018 01:59:47 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 02 May 2018 19:07:30 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.15.2/8.14.4) with ESMTP id w431wZ91026411; Wed, 2 May 2018 18:58:35 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.15.2/8.14.4/Submit) id w431wYtr026410; Wed, 2 May 2018 18:58:34 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 2 May 2018 18:58:34 -0700 From: Doug Ambrisko To: Vincent Hoffman-Kazlauskas Cc: freebsd-hackers@freebsd.org Subject: Re: Can we please finally solve Dell's racadm for FreeBSD? Advice needed Message-ID: <20180503015834.GA25651@ambrisko.com> References: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 01:59:48 -0000 On Mon, Apr 30, 2018 at 11:44:14AM +0100, Vincent Hoffman-Kazlauskas wrote: | for a quick tl;dr | kldload ipmi | pkg install freeipmi ipmitool | dmidecode --string system-product-name | PowerEdge R420 | [root@brittlestar ~]# ipmi-sensors | head -4 | ID | Name | Type | Reading | Units | | Event | 1 | SEL | Event Logging Disabled | N/A | N/A | N/A | 2 | Intrusion | Physical Security | N/A | N/A | | 'OK' | 11 | Fan1A | Fan | 6240.00 | RPM | | 'OK' | | | or for an r210 | root@helios:~ # ipmi-sensors | grep -i intr | 31 | Intrusion | Physical Security | N/A | N/A | 'OK' | | see also the rest of the freeipmi utils and maybe ipmitool for a | different interface (I prefer it for some uses) FYI, Dell used to send patches to the ipmitool project for various extra things they had such as changing text on the LCD etc. I forget if they ever got checked into ipmitool. They would send it to the mailing list. I haven't delt with Dell machines for a long time ... working more with Cisco UCS machines. Doug A. From owner-freebsd-hackers@freebsd.org Thu May 3 08:48:35 2018 Return-Path: Delivered-To: freebsd-hackers@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 1C16AFC9E38 for ; Thu, 3 May 2018 08:48:35 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 737997F4C5 for ; Thu, 3 May 2018 08:48:34 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f50.google.com with SMTP id u21-v6so24785540lfu.9 for ; Thu, 03 May 2018 01:48: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:from:subject:to:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=jwUcWUwrDeurIi8TLkhnh4tAl9Wuj7s0ocqXtXjf9zU=; b=W4dAFSRAVMPdfoq51bc0BSQq73HW9Og3ShE2Lq+mUCa57Grh/L1witT8b+l6lEp7TB oSuA9eIAZbEgKvjXj/0F9K5R9yeecYhskVWT8EohgfYACHCh2wgy2TLAFICpoZlKbOo+ TfhiPPlDtJNlXNYdcoZ6cb2/DhykPgqlOhrHTSLoX4u0r2FZ77acSM1qDqYPFhXs0Uxn PWL3ZRmIPNP/txTBDK5PdmXXiP7OCZ3roFHu3SPrqLrfu2weSmJJtwpidh1LGhXY4aiw gyvV0zlckiK33sN1R2sY2g2ebgNY2NRi0ukkHFt55LOXbM/+u8e42/j7wNU809VVCoL2 /Uhg== X-Gm-Message-State: ALQs6tCouNn8ZkktI0LzBMceJli6p45Tek2XTEVJjQuKKjsiLSo3XFWg ZE2b++LsiDlOQbLSXLgXHyqwRf1n X-Google-Smtp-Source: AB8JxZrWK/GX1VdvhfyoaRIo52h5uZPgLxRFhoXce0jo3tsJ49S7/WaMXFuIkul38dciA+BqEERrew== X-Received: by 2002:a2e:1d53:: with SMTP id d80-v6mr16132911ljd.104.1525336826141; Thu, 03 May 2018 01:40:26 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id z184-v6sm2687698lfa.55.2018.05.03.01.40.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 01:40:25 -0700 (PDT) From: Andriy Gapon Subject: hpet vs suspend to ram To: "freebsd-hackers@freebsd.org" Openpgp: preference=signencrypt Autocrypt: addr=avg@icyb.net.ua; prefer-encrypt=mutual; keydata= xsFNBFm4L6gBEACm5403dDSB1czwNG5iSjFG7c95CL0i8Ayt53jb4SYIyI32enHiGRToLlaQ feTHHIgI8Y9p//1vQ1j/XEcA3jyNVCUuIlTEmBwK2L22OUuOcmlD87UKW/xrvRhOPuU9Toep B3CmOLSSF/Jz5CzFHgtkcRVgfRgoMUtUEZE+YlKm/1ekJx+lL4NlsG+/pv0VCRrQ9SkVT8El 02zugnBJ2AMkLZq57P2Qp+uKF5b/CbaCxeKWT7sjegxZ1wuLwHlcz0oquPuNW+mag3gxa+bV lJNZ0/VgM023KPNKVtK5Gfb9DYld0l9uP8lwIIt35XEbsOsNY2qBZwTx03HzbCBGL3VoEADx 0/UG9fAW97e4S/BzMFdvhd+oPP3ssKZ3XsOESvfeT/iwsEVCWkqP+fX+jzBNC0AT18Oz90BF FUAyKkAA5H70CxYBv3XZizBS4sBSQvXD0cAV5AEh3ThMLeW2JbrOBLNhJosJOCz2ElC7QKcT H2X2w9+TGIEuOtZSCDKbLD7LlgoR7aTpmvE2O6zGeo2Fygj5x5APUj3nzrMOWYCxtMEV09Xu W7yhKfyPnlmBjjiJqGNYO1VY8LqPK+OS3NUuMc2lp0Qydz7/7n4DYda4xL8K5kQi6e9vf86h gI6+55XcwNgV7pERR2y0qCcGvK3qJegexg63GF0x9TCVY7qoVwARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BpY3liLm5ldC51YT7CwZQEEwEIAD4WIQTV4uNvjqdoukGtAHejgLfN2M+qTAUC WbgvqAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRCjgLfN2M+qTIwQEACE TSqU6QXZHm7BSI6VTKhJ+Zn94JBdVTxN1BBoUqVR/RPepWZfoTuZr8DqHC0zmHuCUy1K4uXk /kfYkSearPIsI1EHMKu8/R96qhfA3JGolnQg8M5gc91C8JLDS9UYFTK5CJecG6if/r0LEO4E HxtMr/C+8Vb8vabBBfQPYpCCxG1iMneFZ0/qaAUY+is5ZIlQu9MaJXvWN9BRu2eHmx1IXwDj /vdX8ucf4gsXaq+3eQ4QgGf7f7LJ8TZyq0LB+hamfAaqgODJyah7BxnRTVQh3pwcyrzlV6q6 GI9hqmtGlFZXITdksfzIxRwkAdbiwopP5Sahw6NLOTBXXPTS1fvb1vkfNbGo6xhkH0TPsNj2 bM5hJx2t8+wNSxv8y4i72ne51MqR+NtZhJh89seZQXpHRNPR8BeIXXJGjU5omQKLCxNQQYIz CpK7j7V46164MToG61RVy6yGkLQpvLXRAl9P393OzcyKLcxe4T+oLA6H61MEDoZBP0rxS1KJ ctcZEtnEo6uABmdQTNyEU5WkF98IuRYzzAP0Vz+PCh2yrIt+0qbAjW08f5f7V5OjVS6+gW/v 052cutmOidKCjsJhfYh3/u6k9a1/v4H+OH7IsqbnYGYvxJOin+OZty28+Jc8a35mL5sjNN5j SFWlBYGXvs5lbpR33H7+9I7Tn2KWhgUTWM7BTQRZuC+oARAAtww55amYzgpXAvfKbpcrNuOe Hn8jxPllfAjSDIUBX4c/iT3YwZhvwdTmF+WfZ4Jy6GUKaUPFeFU0xkmqwUKrh0KgTl0cmS/T 7EUOhQkayPFptKpFWnDeP9uL+g3mpkDskZWZ6oRWds4AUGzKiswl2MZdKldAtQRs4VrL+G1B bgm4xmGGbY44mBPBFPNtbHPgcHcKSjPR/GO0w7qLoejgQxv7mB+jPKzL8qK21w7za3d66rLQ owfp0r3tSja37lb0jBXSFhr0I0jiGlp75ZVCTq1yvoYYarGWfff50vbe1SVRanMFzwBLrkr6 hfGebOokPvmBIL0ghCfa5PVu6GSx5tKv4I9FftvVseAWDkSGLbQ64ABaJUkRRqDuKfyaN1FR XxsmzGXH9Cg4OZ3snvpREH0ne3E+Qr/3ORKOsGEA9n3mXljplFhwzPS3pB54v/S9G9EQbbPC cMFUo2MuQz34bix4WCM9oVEBPf/br5ZO7yy2VZTTQvvX+SvAlNHqGUc/qb1RA/YGykFlIaR0 FwBPFXd0AWJXl/LvOQHwV6NyrcTFCKROEGwcHPekWOK89ygEOvPFanHp3+9vEDwHbAlMgK1e XFg13UUhauLXdCvgOGgHkIcHmzVQmWqjg9K4W75o/aney80EGblb128dc5fPq/LPAzBlqDvG bieiCJElcE8AEQEAAcLBfAQYAQgAJhYhBNXi42+Op2i6Qa0Ad6OAt83Yz6pMBQJZuC+oAhsM BQkFo5qAAAoJEKOAt83Yz6pM5Z8P/jw8laEggveeuLUZ3vhVIlMz7EnsUvBmBey9C+1ZArnT k3ZJ8dGIVpQRKl3zXk3CM6tZ6KLaZ4A9f9N2eb5J8zrfiqjqEeKyOj2seQYaZ2dnN+4E7h+O bS+/fA49Ey9TIzseq+sbUvjMFzf7JohNILHSnE3pqdJYMNKpZRAI+U/aRexDH3THS1ejIT/0 c84YZxh0tit13aAdAuDxBvDCZWALhTHlQUSikxjYoIOf0ENG3P2CXWTLP1CsuBwo5IoFnsEQ C82oETblgin6PSP9Snj0GZuj51w6gQfr2D1P1eE0iuF1wEMNujdaZ+QlEaUOLmnBdsK06Xtm HuaRzzS5Vm/E/VUcUuMSQM202tnAYHjSOaBBGRzKBq1zljqsWdwcMl+HEjGuaP6IfVDCYnx6 rq+3sQgJvdrH5DcdHrm8I9GQmwIgTfEwXz+CmeOoDPocE1r6JDq3sW3zF5SKD7o079ga3jev PyzATAYSBlLEPP4xllHs84jH831kropJwBKQejLGevFO5YpFStl737zZlUKgfEX6u66HFhJn 5qUhqPyH7R/MhXiqjpTJpZW2Ez7uam8xKb9hVkSa9mpsd60TRjHT4rFys7x17ZbFlmGr+CPO PcVcvHggw45RwlPTBJ5QHQ1eFZBLxUb/FYwaH52Fj5Zej/v5bbcxbzhISop7o13R Message-ID: <8d3f5a6f-f2be-f2e1-18d5-f774f4909694@icyb.net.ua> Date: Thu, 3 May 2018 11:40:24 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 08:48:35 -0000 Just want to share a strange problem that I see on one system. If I use HPET as an eventtimer, then after a seemingly successful resume the system starts to act weird. It becomes unresponsive for periods of time, then it gets more normal, then it's sluggish, then unresponsive again. After some time struggling the system finally locks up entirely. I see this problem both with FreeBSD and Linux (tested with Ubuntu 16 and 17). If I use any other timer hardware, then everything is okay. Also, if I switch to HPET after a resume, then it's okay too. I tried uncommenting the code in acpi_hpet.c that disables the HPET before suspend, but it didn't change anything. I suspect that the problem is with SMM code, but don't know how to check it or whether it would make any difference. I also tried disabling various devices (e.g. USB) through BIOS config, but that also didn't help. The system uses Asus M4A89GTD PRO motherboard. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu May 3 09:56:10 2018 Return-Path: Delivered-To: freebsd-hackers@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 4C9CBFCBC24 for ; Thu, 3 May 2018 09:56:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 BA3D06EEEA; Thu, 3 May 2018 09:56:09 +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 w439twsq014961 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 May 2018 12:56:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w439twsq014961 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w439twmR014959; Thu, 3 May 2018 12:55:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 May 2018 12:55:58 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: "freebsd-hackers@freebsd.org" Subject: Re: hpet vs suspend to ram Message-ID: <20180503095558.GJ6887@kib.kiev.ua> References: <8d3f5a6f-f2be-f2e1-18d5-f774f4909694@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d3f5a6f-f2be-f2e1-18d5-f774f4909694@icyb.net.ua> User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 09:56:10 -0000 On Thu, May 03, 2018 at 11:40:24AM +0300, Andriy Gapon wrote: > > Just want to share a strange problem that I see on one system. > > If I use HPET as an eventtimer, then after a seemingly successful resume > the system starts to act weird. It becomes unresponsive for periods of > time, then it gets more normal, then it's sluggish, then unresponsive > again. After some time struggling the system finally locks up entirely. > > I see this problem both with FreeBSD and Linux (tested with Ubuntu 16 > and 17). > > If I use any other timer hardware, then everything is okay. > Also, if I switch to HPET after a resume, then it's okay too. > I tried uncommenting the code in acpi_hpet.c that disables the HPET > before suspend, but it didn't change anything. > > I suspect that the problem is with SMM code, but don't know how to check > it or whether it would make any difference. > I also tried disabling various devices (e.g. USB) through BIOS config, but that > also didn't help. Did you tried to clear comparators, besides disabling the HPET ? > > The system uses Asus M4A89GTD PRO motherboard. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu May 3 11:50:35 2018 Return-Path: Delivered-To: freebsd-hackers@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 101A3FA7E90 for ; Thu, 3 May 2018 11:50:35 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6934085AA8 for ; Thu, 3 May 2018 11:50:34 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f50.google.com with SMTP id u21-v6so25513901lfu.9 for ; Thu, 03 May 2018 04:50: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:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=06gyRjDcvod3PiATs6U+zltm4xeDely4FS3OhC31dVk=; b=pkxU+Zm4ZNqEmIrKjw4260PjsU/PdvNaaC8GUlroLX3QXoZzs1t3o5U3agftPfEvFw +3YST0ZxZSmfEIqDf1CqmPtnnMDAjo8k5BQckBfIBkW0NqUYTZZ8bgAp2p/RRf46P315 HXaCczdxr6B4xuvNW/dgdGMzSDESKEZExzqyTjuLSlMTrNWf0U5lt8joQP5YtimlNEMI pyEgrmqyxAKga90bhNdsu8dhBDY2p2o5hX13M0m4lxKMSqGEuHOvg32tZ+RBr06I50zq v/FSXUDir2N7gw5jmQlnbu7x/zuno3AroPz6ojEnPJerqOrGVOmkfrMV3WYju1qkfgI2 lPXQ== X-Gm-Message-State: ALQs6tAU+hBLYEDVNh1KkXFM2jBPlNIqfKS7cbVVx2WFauMRs1D8pecy X9hjj2DfDSjimfxSe7J6Av5AHuJZ X-Google-Smtp-Source: AB8JxZq7NJaF767Ng8X7FT5H8llkNEpv2IDA9C//WBxq+2exFBgr0IJWIwK7FgRwXzImMjWuZWuFZA== X-Received: by 2002:a2e:2a45:: with SMTP id q66-v6mr10132117ljq.40.1525348232480; Thu, 03 May 2018 04:50:32 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id n76-v6sm2746510lja.31.2018.05.03.04.50.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 04:50:31 -0700 (PDT) Subject: Re: hpet vs suspend to ram To: Konstantin Belousov Cc: "freebsd-hackers@freebsd.org" References: <8d3f5a6f-f2be-f2e1-18d5-f774f4909694@icyb.net.ua> <20180503095558.GJ6887@kib.kiev.ua> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+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/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+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 HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM 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: <18935a5e-cd60-a434-f226-1c4ab258c044@FreeBSD.org> Date: Thu, 3 May 2018 14:50:30 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180503095558.GJ6887@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 11:50:35 -0000 On 03/05/2018 12:55, Konstantin Belousov wrote: > On Thu, May 03, 2018 at 11:40:24AM +0300, Andriy Gapon wrote: >> >> Just want to share a strange problem that I see on one system. >> >> If I use HPET as an eventtimer, then after a seemingly successful resume >> the system starts to act weird. It becomes unresponsive for periods of >> time, then it gets more normal, then it's sluggish, then unresponsive >> again. After some time struggling the system finally locks up entirely. >> >> I see this problem both with FreeBSD and Linux (tested with Ubuntu 16 >> and 17). >> >> If I use any other timer hardware, then everything is okay. >> Also, if I switch to HPET after a resume, then it's okay too. >> I tried uncommenting the code in acpi_hpet.c that disables the HPET >> before suspend, but it didn't change anything. >> >> I suspect that the problem is with SMM code, but don't know how to check >> it or whether it would make any difference. >> I also tried disabling various devices (e.g. USB) through BIOS config, but that >> also didn't help. > Did you tried to clear comparators, besides disabling the HPET ? Thank you very much for the suggestion! It seems that doing that (and a little bit more[*]) helps indeed. However there seems to be another issue. hpet_suspend() is called too early. [Some] Other drivers require a working event timer for their suspend routines. So after HPET is stopped the suspend process gets stuck. Repeatedly pressing keyboard keys helps the process to finally reach the firmware suspend. Everything is okay after resume. [*] The change: @@ -838,15 +842,29 @@ static int hpet_suspend(device_t dev) { -// struct hpet_softc *sc; + struct hpet_softc *sc; + struct hpet_timer *t; + int i; /* * Disable the timer during suspend. The timer will not lose * its state in S1 or S2, but we are required to disable * it. */ -// sc = device_get_softc(dev); -// hpet_disable(sc); + sc = device_get_softc(dev); + hpet_disable(sc); + for (i = 0; i < sc->num_timers; i++) { + t = &sc->t[i]; + + /* + * Clear timer state to minimize chances of confusing + * the firmware after resuming from S3. + */ + bus_write_4(sc->mem_res, HPET_TIMER_CAP_CNF(t->num), + t->caps & ~(HPET_TCNF_INT_ENB | HPET_TCNF_TYPE)); + bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num), 0); + bus_write_4(sc->mem_res, HPET_ISR, 1 << t->num); + } return (0); } -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu May 3 11:58:03 2018 Return-Path: Delivered-To: freebsd-hackers@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 8EFCFFA824E for ; Thu, 3 May 2018 11:58:03 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E92FB6864C; Thu, 3 May 2018 11:58:02 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f46.google.com with SMTP id y72-v6so11808307lfd.2; Thu, 03 May 2018 04:58:02 -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:from:to:cc:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=w0/KHc+HDWZGAzWfs4WUE7EncYMUtxwWlNreUr7mgBY=; b=MjVcN1qRWxb5+Y8MfhJZanykcMDvF3HAF/mpXgBG0q20kl63DtEdxvqgtoxyviF0IM 1K767EjTfZ4mbFgzI+y8RPMP9X87q2E263YXtKpIZ/5zLPa8kBC3Y3X3fPYCm+JxPRIf ifpTD2u0/qpfTVNNSsPrLA9xk2EjABgMeEpTqI2xTMbKiTHzeusPZrMPAksinnqx7ThG r6907ZAI16Vc2XiutO5KIlKvJxUJYyVKniPnPXO0Apzd5hZ6DKAl88vUdNjSLvGZYOtV UlLtTbI0FG3Jjx0iBqbudA8/s8B4IG/Nx0TIyHstHZ/trnKHqhfkcajdhQoiKJMuAn9T /u6w== X-Gm-Message-State: ALQs6tBZu5JfWuGQ4fexfB4lUXnqIIeDHlyMoNqELrHMHSe/O08zYYHX wZNWe/Ea7UwXp6S1iA39uS3wIOjh X-Google-Smtp-Source: AB8JxZq8jNcI+vWYh0N2J/E8Fwk9gaGft4bCy7h2DhXEGxYaP+oOLs5rKD37joSF9rfvDLVc0AZAqQ== X-Received: by 2002:a19:5a1d:: with SMTP id o29-v6mr13983491lfb.93.1525348681160; Thu, 03 May 2018 04:58:01 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id o11-v6sm2807951ljc.77.2018.05.03.04.58.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 04:58:00 -0700 (PDT) Subject: Re: hpet vs suspend to ram From: Andriy Gapon To: Konstantin Belousov Cc: "freebsd-hackers@freebsd.org" References: <8d3f5a6f-f2be-f2e1-18d5-f774f4909694@icyb.net.ua> <20180503095558.GJ6887@kib.kiev.ua> <18935a5e-cd60-a434-f226-1c4ab258c044@FreeBSD.org> Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+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/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+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 HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM 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: <39dad33d-3983-c85f-5049-e3b934800829@FreeBSD.org> Date: Thu, 3 May 2018 14:57:59 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <18935a5e-cd60-a434-f226-1c4ab258c044@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 11:58:03 -0000 On 03/05/2018 14:50, Andriy Gapon wrote: > Thank you very much for the suggestion! > It seems that doing that (and a little bit more[*]) helps indeed. > > However there seems to be another issue. > hpet_suspend() is called too early. [Some] Other drivers require a working > event timer for their suspend routines. So after HPET is stopped the suspend > process gets stuck. Repeatedly pressing keyboard keys helps the process to > finally reach the firmware suspend. Everything is okay after resume. Got a patch for this issue as well. The idea is to suspend children in the reverse order (comparing to their attach order). --- a/sys/kern/subr_bus.c +++ b/sys/kern/subr_bus.c @@ -3772,15 +3772,16 @@ int bus_generic_suspend(device_t dev) { int error; - device_t child, child2; + device_t child; - TAILQ_FOREACH(child, &dev->children, link) { + TAILQ_FOREACH_REVERSE(child, &dev->children, device_list, link) { error = BUS_SUSPEND_CHILD(dev, child); - if (error) { - for (child2 = TAILQ_FIRST(&dev->children); - child2 && child2 != child; - child2 = TAILQ_NEXT(child2, link)) - BUS_RESUME_CHILD(dev, child2); + if (error != 0) { + child = TAILQ_NEXT(child, link); + if (child != NULL) { + TAILQ_FOREACH_FROM(child, &dev->children, link) + BUS_RESUME_CHILD(dev, child); + } return (error); } } -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu May 3 21:32:45 2018 Return-Path: Delivered-To: freebsd-hackers@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 CF574FBB9A9; Thu, 3 May 2018 21:32:45 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65E8D68F2B; Thu, 3 May 2018 21:32:45 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-it0-x244.google.com with SMTP id 70-v6so1090744ity.2; Thu, 03 May 2018 14:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=XxLfZ7Zbn9+l4GkAhiCJr95bEI5408ZqfU+DiQY8wLw=; b=tW6srtrgqSWLdyHJqk76znaojXNMwkdrpI6ql/mHAp+mVU550oaLwGgGyVoyjx0WCm qtkD3PLr9Q112RkVEwNGM970QSU4ebjeg88qNetm9SM4GR4d0WZCgzl+TBQHr1QJ6GeF bz11gChqmSql7pPXG+9ANzBUCS8qjYXhtef56NVqjaFHJMZPRYanP0I+uBlJLEaNpbRz vfYSVEGdHzQPY+VX+hvT08giAmpRdJ0xpdn5UrztrwzuJv3YnfY+vv98JGhOz3p9ZObk X8VaAFVxBdGr4VJkrhlQ9gvB9NXuN1ZyS6izzCWOmxMvTkHtVDs8yBlHY6FHGiinPJce yFnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=XxLfZ7Zbn9+l4GkAhiCJr95bEI5408ZqfU+DiQY8wLw=; b=N2Rejwb00giCp3KDpw68x6+55tf1S7TpB0Uz5rDOAIragYt8X0oZSJmaE0LKuUVega KFeeO2BcGSVylnbipTp8DxCmQsslh4aOEdMQswIMqi0Wt5rrwI/T7lU3WDYYJoRw4qkw B6PKTXG4lIq0eZtu3vChjylQWDDkbleFlKhIfLU45forkZHVjfjAnZacFthG1NKLVNM7 jWG1TuuIH2rVBbzgHSFvF4bFfrripkizIooZcmZtitdaDRs28C/AMR+TH0BMrUY9PF5A ytD8BpHhReaAibYulK1TvG3Y42WquuORG3YlCyghuceiUfvjPPx3b+GOfa/J/s4S+HwI PtIQ== X-Gm-Message-State: ALQs6tCVLoIW9rN7wu4f6qa2/P09OXZ3H5wjGvlEH6fDoqgC/Xph1her 2QI4Oe+M3UGsBBn7zMuMuRw0Z+3JuzV8B8JYYnc= X-Google-Smtp-Source: AB8JxZpMJiTUOcUeHFjzXfPOm6lOdl8CV2L+zeEgBbtaSv8EjPCo99uVoclJW+BhQ7CErYiDugxWXtlvkfSVfd02pD8= X-Received: by 2002:a24:c4c1:: with SMTP id v184-v6mr21787919itf.41.1525383164719; Thu, 03 May 2018 14:32:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.131.43 with HTTP; Thu, 3 May 2018 14:32:44 -0700 (PDT) From: Dieter BSD Date: Thu, 3 May 2018 14:32:44 -0700 Message-ID: Subject: netstat(1) -s -f is broken To: freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:32:46 -0000 FreeBSD 10.3-RELEASE The fine man page promises: netstat -i | -I interface -s [-46] [-f protocol_family | -p protocol] [-M core] [-N system] Display per-interface statistics for each network protocol, for a particular protocol_family, or for a single protocol. But in reality, netstat -I interface -s -f family only works if family is inet6. interface=lo0 for fam in inet inet6 pfkey atalk netgraph ipx unix link do echo -n interface = $interface fam = $fam netstat -I $interface -s -f $fam | wc done interface = lo0 fam = inet 0 0 0 interface = lo0 fam = inet6 56 258 1728 interface = lo0 fam = pfkey 0 0 0 interface = lo0 fam = atalk 0 0 0 interface = lo0 fam = netgraph 0 0 0 interface = lo0 fam = ipx 0 0 0 interface = lo0 fam = unix 0 0 0 interface = lo0 fam = link 0 0 0 I had this in a loop with all the interfaces, the results are the same for all interfaces. Doesn't work with -p either. netstat -I lo0 -s -p udp :udp: no per-interface stats routine It would be very useful if this actually worked. From owner-freebsd-hackers@freebsd.org Fri May 4 03:56:57 2018 Return-Path: Delivered-To: freebsd-hackers@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 97E4EFC5F3C for ; Fri, 4 May 2018 03:56:57 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BCF37BEC9 for ; Fri, 4 May 2018 03:56:57 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=76.103.75.166; helo=[172.16.1.60]; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from [172.16.1.60] (ice.xse.com [76.103.75.166]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w443usaB037073 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 3 May 2018 20:56:55 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [76.103.75.166] claimed to be [172.16.1.60] From: Craig Leres Subject: nvme0: async event occurred (log page id=0x2) Openpgp: preference=signencrypt Autocrypt: addr=leres@ee.lbl.gov; prefer-encrypt=mutual; keydata= xsDiBEl0NF4RBACDvJCrCDfQLVlLHKYiWka4Jmo62eQnoptSgZ2d56Rsb9NK1kkqDRkTJNuJ 3gTkQZDnNMCC6gDn3QwV7bDEKcvr0TUBU0l8yhuROLx26xHITqTUoBSq2oay9vDcoMoqh09j jL614dSIQ4NiyrL835LBthPF0GwsTHktOKWBpWWwAwCglHOnEbyIA2ddGzqFPFtIWyxjZskD /3MQz8M90gopAbB9fgWL9alqe5DRYgQAEu7PAEydOTzS3dMcrnIiG28ytFuheW8jZyuhi8Nr hpqswuNHxe/quhAFuG5StX/Rqq/E/tU1gCQlicrZ5hE1Nt8Vg7njcoTykXTaXZClhtDrZmiO WbYFHHTx5+OK3MkxrqaPROQ28utdA/9y+J4Aw+LpQzzmp4T/vC0FpOtxg0OfW2UUdt2XR9HN 4gy3C4tqYAPMzZR7el3bPGeDaDs/9ptCm3R/PdTQPr39ICR+3fihQjZSciHjhs7800/jlGa0 MXO1mwGce3RtxqCH3kHT2XqVn3hYr69wv8NQ785Tt5TSRgplMRKcVUVArs0eQ3JhaWcgTGVy ZXMgPGxlcmVzQGVlLmxibC5nb3Y+wmMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX gAUCSXQ+hwIZAQAKCRBbGUCECN7cm0vHAKCFHil4ZVo5wz5T60HfProR0lQX5wCfdLhyR/Sn cy/OIeURce1lAFv7+/jOwU0ESXQ0XhAIAJfIMoCDjRmh3nDACCj/blxqD18+PH5eIWsr2oXk beW4RQA+WTCAl5FsGd2vmvlDU/hHux3UBvqV3CjLqllKdTpOYkxN5oY6oKtc14ELVFcFXFsd sp7JlrIs9Ms5MBis8Um/rqCOQ86kI7ARtRr97PEhnJYb0UpHCxwV3CEKtUso9oraQQ+zyC2u mFx5hsrcibf4OJ69m844AMDCgxKIwPVZeLkxbtqWu/H/ned5O64crqFK/eyHD/eKun8E5LHu YuDtcUOdhfpYgVy7FGldnVtd0Eo+iJIO+cnTPhkHQMjBkNgUCW/jvBl7BNkBMsqgHXSrHzIs jCxNFEryxG0cM78AAwUH/19av/a8hGMHPv7d/Y3e0ilDgho1EOpAQj8gcTb2VYjPw+PWDf+t yjScvSlZYLc8CYqlAbipVBQwfzaJ9LBwCtJfsv1TJA8v4hO5yvPWyHgyQ/8c1vOLZCCvyzWO AH180a+XR99NcV07wpgY74ZP7UHJejiYQmXXScyGp2Qc9CvZMpf120U2vyB0/X8tXaoPC7qY TG6z6A6gizDg8go8Mfcoak6ROMhLJvZllYHSSUPQGiZZJfBz+XwIVGOqxfvyZOwuROfKipvp TdDxhzxt4iTo66c6kwcQWyc3n1kJnOlyIJGS7512htXcpXRjrHB7LAARRbxOvP3uAQhhrz5C mfjCSQQYEQIACQUCSXQ0XgIbDAAKCRBbGUCECN7cm8q0AJ0ZuPOyYcKYCRXwoaiRFtU7PisR CgCfYHU3ZfILghwJKFyTqVWWlRvdO9U= To: freebsd-hackers@freebsd.org Message-ID: <960be682-9991-f8c6-0253-7d6f782d4cbe@freebsd.org> Date: Thu, 3 May 2018 20:56:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.0 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: 0, 76.103.75.166, Ugly c=0 p=0 Source New X-MessageSniffer-Rules: 0-0-0-4215-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 03:56:57 -0000 I have an intel nuc (NUC6i3SYH) that ran 10.3-RELEASE until a few weeks ago and now 11.1-RELEASE. The system disk is an intel 600p M.2 SSD and there is also a 2TB seagate laptop drive (ST2000LM007). Occasionally the system SSD will go to sleep. It happened today with this on the console: nvme0: async event occurred (log page id=0x2) nvme0: resetting controller nvme0: nvme_ctrlr_wait_for_ready called with desired_val = 0 but cc.en = 1 Later it would occasionally print out: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1509, size: 12200 There was an app playing music from the 2TB drive that was still working when I reset the box. But no i/o was occurring with with the M.2 SSD. I see PR 209571 might be related (same async event log anyway at least). Does anyone have suggestions for me? Craig From owner-freebsd-hackers@freebsd.org Fri May 4 04:07:12 2018 Return-Path: Delivered-To: freebsd-hackers@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 D8A0EFC659C for ; Fri, 4 May 2018 04:07:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 702407EDBD for ; Fri, 4 May 2018 04:07:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id d73-v6so24187101iog.3 for ; Thu, 03 May 2018 21:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4FfCVdzuamlluyzQihgevS2wNz5TSRbPCHN5gCXLdL4=; b=P5mR5SUpXYTqoURlJYFiDujZLHLoX88CzBchz568oNfQpE2OrrvqiiONJdG7s50veV xeHLOIzEOZdH5WSjKkv+MoupA4hu+tJrkfu7i+LQdI3yiWwEon+CGGAoPlGftD20VuNR LmmudXVGe4zASxYgywEorULaOQFh0KhSGPJFUFM/yrOS2Jz8AReJzt7Qc6KSb8tu3LRW Y7RktMZ55CJvWQL/wffwVHPp08ePTmBzpXXafY4J/aBzHsPhAKKjmx4SWTE9hL1R8Biw MraWvMUZMRbxSVguMCNr0ZdZliJF8Va+hpxOJvrr7dykB/vfGLC5agi7kk713v1xc5du PE/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4FfCVdzuamlluyzQihgevS2wNz5TSRbPCHN5gCXLdL4=; b=aFIxZCfkI/lbvI8JfHM/NdWf18TVOCKsrYIE54IQllHgbiTud9ZxoOpjkN4ioLo09T rbhqZ82eNePitWSRqmwsmbj4Iv8Uo/RKafsXnwbHlFB03Bxr21zIkv4Iz/PrjJE3W6OP 9b33oxizBKEX50NAFL8USQoQv0oaIeE0aCh2dCRPO1fWDc6v/69x6CCwLltXb9Uvt9lF OFH2MXy5XlTl+EAVJRXXpLZIW3q8XZVioWhXohWsZB+FtM/SwNKknT5Mwb5FG5O5Ll3c PF+xmPUlFq3xzs30SWHxU2OyQ2sx3DJAl8v58nJB/LH/JZ4d/15XLGV75E/0RE36a75G jXGQ== X-Gm-Message-State: ALQs6tBqj2ISrKR/Ed1+Jn8Mm3iU5fDnWiSwBJROjc+SxIuCGd/gjMJD IJm9MZijwPGoCJ10sYEY8nBYMNp40cP58SbuCMtHeA== X-Google-Smtp-Source: AB8JxZoKFD4GpcA09a2qSnHnaX2/KdvxpsnN3ahuMFyAMl+n/MLn5SeINelaj76Bs9pj9i2TVwWDEFAx591y0d0syS8= X-Received: by 2002:a6b:12a3:: with SMTP id 35-v6mr27441720ios.168.1525406830503; Thu, 03 May 2018 21:07:10 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Thu, 3 May 2018 21:07:09 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <960be682-9991-f8c6-0253-7d6f782d4cbe@freebsd.org> References: <960be682-9991-f8c6-0253-7d6f782d4cbe@freebsd.org> From: Warner Losh Date: Thu, 3 May 2018 22:07:09 -0600 X-Google-Sender-Auth: UQ6bPIlx69wUi_jMNm4-xPezeHM Message-ID: Subject: Re: nvme0: async event occurred (log page id=0x2) To: Craig Leres Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 04:07:12 -0000 On Thu, May 3, 2018 at 9:56 PM, Craig Leres wrote: > I have an intel nuc (NUC6i3SYH) that ran 10.3-RELEASE until a few weeks > ago and now 11.1-RELEASE. The system disk is an intel 600p M.2 SSD and > there is also a 2TB seagate laptop drive (ST2000LM007). > > Occasionally the system SSD will go to sleep. It happened today with > this on the console: > > nvme0: async event occurred (log page id=0x2) > nvme0: resetting controller > nvme0: nvme_ctrlr_wait_for_ready called with desired_val = 0 but > cc.en = 1 > > Later it would occasionally print out: > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1509, size: > 12200 > > There was an app playing music from the 2TB drive that was still working > when I reset the box. But no i/o was occurring with with the M.2 SSD. > > I see PR 209571 might be related (same async event log anyway at least). > > Does anyone have suggestions for me? > Async events are 'something went wrong' messages. Log page 2 is the smart log page. what does 'nvmecontrol logpage -p 2 nvme0' tell you right after this happens. My guess is that it's overheating. Warner From owner-freebsd-hackers@freebsd.org Fri May 4 04:28:47 2018 Return-Path: Delivered-To: freebsd-hackers@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 CF34CFC6CF6 for ; Fri, 4 May 2018 04:28:47 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46939843F1 for ; Fri, 4 May 2018 04:28:47 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=76.103.75.166; helo=[172.16.1.60]; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from [172.16.1.60] (ice.xse.com [76.103.75.166]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w444ShRH039806 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 May 2018 21:28:45 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [76.103.75.166] claimed to be [172.16.1.60] Subject: Re: nvme0: async event occurred (log page id=0x2) To: Warner Losh References: <960be682-9991-f8c6-0253-7d6f782d4cbe@freebsd.org> Cc: "freebsd-hackers@freebsd.org" From: Craig Leres Message-ID: <8b1eadc2-8c9d-3f11-b877-b9a0a57512ec@freebsd.org> Date: Thu, 3 May 2018 21:28:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: 0, 76.103.75.166, Ugly c=0.071429 p=0 Source Normal X-MessageSniffer-Rules: 0-0-0-3656-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 04:28:48 -0000 On 5/3/2018 9:07 PM, Warner Losh wrote: > Async events are 'something went wrong' messages. Log page 2 is the > smart log page. > > what does 'nvmecontrol logpage -p 2 nvme0' tell you right after this > happens.  My guess is that it's overheating. Interesting. I try to run smartd anywhere it's supported and have appended the last few entries before things went sideways; 60° C/140° F is a bit toasty! This system is a couple of years old, might be time to blow the dust out with compressed air and see if the bios has more aggressive fan settings. Is the Raw_Read_Error_Rate changed a problem? (Thanks!) Craig May 3 13:59:22 tiny smartd[770]: Device: /dev/ada0, SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 59 to 60 May 3 13:59:22 tiny smartd[770]: Device: /dev/ada0, SMART Usage Attribute: 194 Temperature_Celsius changed from 41 to 40 May 3 14:59:23 tiny smartd[770]: Device: /dev/ada0, SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 60 to 58 May 3 14:59:23 tiny smartd[770]: Device: /dev/ada0, SMART Usage Attribute: 194 Temperature_Celsius changed from 40 to 42 May 3 17:29:23 tiny smartd[770]: Device: /dev/ada0, SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 75 to 76 From owner-freebsd-hackers@freebsd.org Fri May 4 04:33:55 2018 Return-Path: Delivered-To: freebsd-hackers@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 2E76EFC6FFC for ; Fri, 4 May 2018 04:33:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFD7E8638E for ; Fri, 4 May 2018 04:33:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id g1-v6so14877206iob.2 for ; Thu, 03 May 2018 21:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=drw5jUwjEiMX7RdOaJRseS0ViQHUj7eLFbsGj73CxVU=; b=VPvfV7NM9Fyv5+1FUneCs/ZBgzRQRD4djAr1JbRZQ265R/l418CXLhuKyuJzHNySsO RXfjkZY9tA7TJx0PN+chg5kcec3HW2tVM6ZYO9pG0VWHc0RRLnS6bnMGyaIv+XQZ1Yid PLeJuss6SL7Ns7NgwuJBp63eSY45r/u1omlwvj251K2Yt80C4plAuPbPJJtoTpUdyaww nIY/aO+IR2qK8MiBxhWhH1vVyR7C3G1xEEccapOPq70+8I5uldrfRaF/xf+9WaYusnzV /eiTEuRgQJ4mQKhDzb8NliBSSyRmfDYa6xOEl2qpJjp7/g9/4q3TvEqHBmr5LS7URQs8 KULg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=drw5jUwjEiMX7RdOaJRseS0ViQHUj7eLFbsGj73CxVU=; b=MsuBj7ikdnK2xVJYgeVb6DwswggB1v2YSIC52/9mNqIUasWUCwQLPGrZkCpkvW+wW1 ZaxtDT/7Vkyswik2qi0qhWlD+GTBdplkZckCyYkJefzU77gsNYgjFvIL3WWHgmBHuY+1 n2Zj8gRYEqofMhKhpuxPtfta/TKHjpuZtlRYWMl58UHa4QlIRgLF053aemQKKgO6RY4m QxpEZlTUtsNFpNsM4xRw2Ex5I3a5P4P8HGsdwgy8VaENPwAEb+TDEmWHWZ4uOXceTqsA dk+zYhYG4kTySnFApp7eyaRjE7PnXT08pBHPKge8c9sRFpXp2iPk7aOnMA6jh4jLx1Ru 0rkg== X-Gm-Message-State: ALQs6tCJ53GrJDGhfNbs3F2TWiwwRjt7OF3ythFBYu8MaSr1kH8oKneL XbZy9MoXiGNSk6eDs94oqlMfiBTklhyjqXv8nW8sYQ== X-Google-Smtp-Source: AB8JxZqzrx/kgbPQ2Fu429CT74ISjLOfGOLuZCpUhPRLAhl+9MFVsFO04xq2Iaj9hCFf078zRt/VmBbb1pHI/lRMNh4= X-Received: by 2002:a6b:be01:: with SMTP id o1-v6mr26788721iof.299.1525408433987; Thu, 03 May 2018 21:33:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Thu, 3 May 2018 21:33:53 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <8b1eadc2-8c9d-3f11-b877-b9a0a57512ec@freebsd.org> References: <960be682-9991-f8c6-0253-7d6f782d4cbe@freebsd.org> <8b1eadc2-8c9d-3f11-b877-b9a0a57512ec@freebsd.org> From: Warner Losh Date: Thu, 3 May 2018 22:33:53 -0600 X-Google-Sender-Auth: dTFAIcPC0QTq3tQBvqEAFNzxZCE Message-ID: Subject: Re: nvme0: async event occurred (log page id=0x2) To: Craig Leres Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 04:33:55 -0000 On Thu, May 3, 2018 at 10:28 PM, Craig Leres wrote: > On 5/3/2018 9:07 PM, Warner Losh wrote: > > Async events are 'something went wrong' messages. Log page 2 is the > > smart log page. > > > > what does 'nvmecontrol logpage -p 2 nvme0' tell you right after this > > happens. My guess is that it's overheating. > > Interesting. I try to run smartd anywhere it's supported and have > appended the last few entries before things went sideways; 60=C2=B0 C/140= =C2=B0 F > is a bit toasty! > > This system is a couple of years old, might be time to blow the dust out > with compressed air and see if the bios has more aggressive fan settings. > > Is the Raw_Read_Error_Rate changed a problem? > > (Thanks!) > > Craig > > May 3 13:59:22 tiny smartd[770]: Device: /dev/ada0, SMART Usage > Attribute: 190 Airflow_Temperature_Cel changed from 59 to 60 > May 3 13:59:22 tiny smartd[770]: Device: /dev/ada0, SMART Usage > Attribute: 194 Temperature_Celsius changed from 41 to 40 > May 3 14:59:23 tiny smartd[770]: Device: /dev/ada0, SMART Usage > Attribute: 190 Airflow_Temperature_Cel changed from 60 to 58 > May 3 14:59:23 tiny smartd[770]: Device: /dev/ada0, SMART Usage > Attribute: 194 Temperature_Celsius changed from 40 to 42 > May 3 17:29:23 tiny smartd[770]: Device: /dev/ada0, SMART Prefailure > Attribute: 1 Raw_Read_Error_Rate changed from 75 to 76 > Things are getting hot, and there was a recoverable error (since you didn't report a read error, though you could also check page 1 for any errors). Chances are the controller shut down completely (though from just a few data points you've given aren't enough for me to be sure). Warner From owner-freebsd-hackers@freebsd.org Fri May 4 10:22:13 2018 Return-Path: Delivered-To: freebsd-hackers@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 45970FA88E7; Fri, 4 May 2018 10:22:13 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward102p.mail.yandex.net (forward102p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B13F2722C4; Fri, 4 May 2018 10:22:12 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback10j.mail.yandex.net (mxback10j.mail.yandex.net [IPv6:2a02:6b8:0:1619::113]) by forward102p.mail.yandex.net (Yandex) with ESMTP id 4E9A7430463B; Fri, 4 May 2018 13:22:02 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback10j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jXvSB8I1XI-M2XG10cS; Fri, 04 May 2018 13:22:02 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1525429322; bh=C0suh/MH/lzHHLdvu7DpttfyLAYTvwpZ9TTJ+S3rPMw=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=TeoxSnRb5j6ECplbyu1yZ3YcYrBeImcDSKn39vUVIeN2FKMO0Af29XrEMHmX5lDLr /hEqxjr12sJ11zujwKnN/A84NHkKPZNJHl2pccK/YRVSQWdYpow9IjcCSwYA1Wtoyk vB3/5usKjouaR6Iyig9Ez+EcMJUfuFsSUsyibI/s= Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id yBH1Ej2S98-M1NqaE5b; Fri, 04 May 2018 13:22:01 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1525429321; bh=C0suh/MH/lzHHLdvu7DpttfyLAYTvwpZ9TTJ+S3rPMw=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=MMGwuZt7RBLsFSnUQ7f7NgXQ3634s9Qh08QBUbBNZ73nw8hyl4eXm45GaZ+n7wRoF jqR2c6Ja4OlTqr/Xt1PaodmZ4+t8FboK0GqAqCt8aYl1lYRn9+l9vpb7ezNxZJa9I+ UnqSfaYAz9PnX3wDIWSmY2sgtAtjfmTwEp0CUdtY= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: netstat(1) -s -f is broken To: Dieter BSD , freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org References: From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: Date: Fri, 4 May 2018 13:19:57 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VQ7FBkkI6si8brz3m7ulIZi9Qgk0G0JTS" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 10:22:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VQ7FBkkI6si8brz3m7ulIZi9Qgk0G0JTS Content-Type: multipart/mixed; boundary="jiNzG0IhPgBcjl5lpYDC7aHS52sxPbVEm"; protected-headers="v1" From: "Andrey V. Elsukov" To: Dieter BSD , freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org Message-ID: Subject: Re: netstat(1) -s -f is broken References: In-Reply-To: --jiNzG0IhPgBcjl5lpYDC7aHS52sxPbVEm Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04.05.2018 00:32, Dieter BSD wrote: > Doesn't work with -p either. > netstat -I lo0 -s -p udp > :udp: no per-interface stats routine >=20 > It would be very useful if this actually worked. Only IPv6 and ICMPv6 have per-interface statistics counters. Other protocols don't have such support. --=20 WBR, Andrey V. Elsukov --jiNzG0IhPgBcjl5lpYDC7aHS52sxPbVEm-- --VQ7FBkkI6si8brz3m7ulIZi9Qgk0G0JTS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlrsM84ACgkQAcXqBBDI oXrHbgf+I6KRGpRoc3jIq8ISiinr9x63mz0Kx7KVB/Sf+z4kaTYMLxwVASUEz7Zv mnoaaZTchBeKy3zMKHLWe/88LXJqfTt3zZ824oZC/QS9rjztXUKsvw9ei6Zkc+Oo ZOwY7E9Oc7pkB95i/pDRtOVxoNziokiOgUA0Uc1H5wuYVUW35FziXDS4lnbnZjcQ 5RjKsN3nis3gdq2fYQPFl7ir4dYza2/MyiVtos9LISWg1UbS8IfDG8n1EGpV1h0J YLyPul9T1Y6dGXq5WSPuXdM1iCHXGPmnOcsXMXkN5qm6k9A/m3CTk36gWtT1ekN6 GA0H9RDCRdYwVdHKnghAAVBMgqa6Xw== =Z+Ff -----END PGP SIGNATURE----- --VQ7FBkkI6si8brz3m7ulIZi9Qgk0G0JTS-- From owner-freebsd-hackers@freebsd.org Sat May 5 00:59:35 2018 Return-Path: Delivered-To: freebsd-hackers@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 6999DFBE967; Sat, 5 May 2018 00:59:35 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E345B7FF0B; Sat, 5 May 2018 00:59:34 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id n10-v6so7529635wmc.1; Fri, 04 May 2018 17:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=vQ8pHV8rRwg0y0gqcc9s+eOe6STNkdcUnYnGXgVRSVY=; b=VCEKCnU7ewbDdL83rR08rt2lgiQpvlRO94kWRmtdPRv5mzUBU3beLBy8BE7gqE88yD zIWONFY6nrJj1inyW4yQGrjxQdR5Zx3OgS1tO0zKkyPqBxmMTP8jSz6KzJwHEmlXMEWA LHcDAouidJMvxTJas/u/HXzVNw6d2KJy023w1gRtZL0VQyyGXcSFkusIs3QHOdTUdcuN 3m+Y/Eo4mllvnlkHQoIwoZgC0QVO2mXpU1pryi2D/tle7KbrrTL5O04wfkD+EfQn+lRh Nl81JuIn0XQEBMduLSTCGuKcLL/VjdlmFxq/uRErhE30DKzSV0QuJ4ebYOPK0yLxSYz3 z4yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=vQ8pHV8rRwg0y0gqcc9s+eOe6STNkdcUnYnGXgVRSVY=; b=dNxC5sgqlc/zNQAhU5KvYUI2E1Ojhw9cykGW5Tc3Yyd/oqU+5WOntjOw1/y08DYqN5 plsSCVlCT6rFY4B7uckA/ajeMsYoaAtY4/5Gdfx86/8xVRU0qZW/3CvifLsEKM43FWeL DzaRlQG/Mt5eY1c2W5QXGwnmaoSjpiOX/cGRmBsTkTbzZZ1fEWtD21jgBza6zIxKkQoY DIcda8zR1Ij+wyyXQ1FIXICDg53zQkPD5vRt8eDlgW1zpX0VXXzXZsTBNxiHWvH/bD2T qKWCzrxl3Du6rniHILvzHmcgUbBOOzleCuzqVQpTXDQtDVgvnCgLHDkvXb/Pz30IKAph r9GA== X-Gm-Message-State: ALQs6tCkzRB0A8+CSxHsBRll0P/ZAEJMMPtxVwvnf5Bp8h98RaWDWc8W oKap2yR9dLlIN+ztQPF5QPHUaCe1 X-Google-Smtp-Source: AB8JxZrVpam14Jj8F4cxRUuzupaAi9cgz0pMyNF7PnvIkDw26UKi5Iq+yy0wGYU+F93BVOz8DbCQoA== X-Received: by 2002:a50:92e6:: with SMTP id l35-v6mr39145526eda.98.1525481973665; Fri, 04 May 2018 17:59:33 -0700 (PDT) Received: from localhost ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id p5-v6sm9839020edh.7.2018.05.04.17.59.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 04 May 2018 17:59:32 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 5 May 2018 03:59:31 +0300 To: freebsd-current@freebsd.org, FreeBSD Hackers , bdrewery@FreeBSD.org Cc: Rozhuk Ivan Subject: SSP_CFLAGS for kernel Message-ID: <20180505035931.33120d74@gmail.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 00:59:35 -0000 Hi! I set: /etc/src.conf: WITH_SSP= /etc/make.conf: SSP_CFLAGS=-fstack-protector-all WITH_SSP_PORTS=yes But in /usr/src/sys/conf/kern.mk: ... # # GCC SSP support # .if ${MK_SSP} != "no" && \ ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" CFLAGS+= -fstack-protector .endif ... Is there should be some thing like in /usr/src/share/mk/bsd.sys.mk: SSP_CFLAGS?= -fstack-protector CFLAGS+= ${SSP_CFLAGS} ??? PS: /usr/ports/UPDATING "The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all" should be: "The default SSP_CFLAGS is -fstack-protector, but -fstack-protector-all" From owner-freebsd-hackers@freebsd.org Sat May 5 10:38:40 2018 Return-Path: Delivered-To: freebsd-hackers@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 05518FA97FF; Sat, 5 May 2018 10:38:40 +0000 (UTC) (envelope-from m.bryn1u@gmail.com) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DC8B7F888; Sat, 5 May 2018 10:38:39 +0000 (UTC) (envelope-from m.bryn1u@gmail.com) Received: by mail-lf0-x243.google.com with SMTP id o123-v6so34286121lfe.8; Sat, 05 May 2018 03:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6IkhIoWTSl1S2twi3R9ZVjTEpeN9sld5u0Fc253lZQ4=; b=Ys7Lc3ifPnXIIUjYeEQ8QOmjIEifFgBHSWUbISvdmLeoujlaqSIrvj7jD6PmfvCtPS BlutP7srCmT5QS65wLBezES8FRYhTX3YPug9MlbrBnehTRiWft5AvuiZiD4s9dTFlCFk inc7ZQER0Z28ZGi1UZ/QBk3VGpOshPbjmNQknfR168K2kXseNEiqYjtIjSVJF4N+k3VW UatvgG+YNyQglwS63OW3v5BevHWImAxH+l90Pa0DhN9Jensqbo5dTWpUrm+uXEv39/sU OQ1htzloqzjD9Z1PU1cc7wHSeH8dEMoXmXUieuOcLErSAXIfa/yXEfG/dt47VXmhi7ZD 8FQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6IkhIoWTSl1S2twi3R9ZVjTEpeN9sld5u0Fc253lZQ4=; b=Q4d/88ruRZtnowrKjb+KAMlOL46TbKLE52V+KKOI1Zr5XTH546bfHWLDTAbciACGnv 3qnPpU0PkFbOaJK0ev7aCE6pJPxkpYMlhdUQLjG6HiVn/4uZdE6S1VBmt48WZgDodBRQ 7bBwgtstoAZFiRGnHgxZY2eK5E06TUB7O3tqXhH7I0RBgEV7rY8mFCKaJhEp5MetcKiv qxc6u7+n4+vt2UvgOY0h+O7WewOu5QrFcK2WWl4jujbDjyRfLkcLGPJOz/GQDcu7PjFh wF+CrA8/U+YLfRN1V9yUQSaYDMAOhF2Q9sd6bZYGqWlkYD/J61S1yU/zhkGOlebXDxws yW/Q== X-Gm-Message-State: ALQs6tAMmwxjM5UqUvRpdUaDZYwCbQxhwrBcWwG26l1AN/AimpaFlmLs jVH1RckQFqjTK/H02Kl3+GKa4Mix9z50cZUDpTE= X-Google-Smtp-Source: AB8JxZrq1ldNBAjBWLVgJCQn48cwnCUcgBWYZ5rwPn6DLhLsKDXXxKL5q8F3y8cI/tXVdfclxhNmkwbW1MxdGDdfxv8= X-Received: by 2002:a2e:2a45:: with SMTP id q66-v6mr15085588ljq.40.1525516718062; Sat, 05 May 2018 03:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.71.139 with HTTP; Sat, 5 May 2018 03:38:37 -0700 (PDT) In-Reply-To: <20180505035931.33120d74@gmail.com> References: <20180505035931.33120d74@gmail.com> From: bryn1u85 Date: Sat, 5 May 2018 12:38:37 +0200 Message-ID: Subject: Re: SSP_CFLAGS for kernel To: Rozhuk Ivan Cc: freebsd-current@freebsd.org, FreeBSD Hackers , bdrewery@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 10:38:40 -0000 Hey, Don't touch src.conf Entry for make.conf should looks like below: WITH_SSP_PORTS=YES SSP_CFLAGS=-fstack-protector-all SSP_CXXFLAGS=-fstack-protector-all It's working for me. 2018-05-05 2:59 GMT+02:00 Rozhuk Ivan : > Hi! > > I set: > > /etc/src.conf: > WITH_SSP= > > /etc/make.conf: > SSP_CFLAGS=-fstack-protector-all > WITH_SSP_PORTS=yes > > > But in /usr/src/sys/conf/kern.mk: > > ... > # > # GCC SSP support > # > .if ${MK_SSP} != "no" && \ > ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" > CFLAGS+= -fstack-protector > .endif > ... > > > Is there should be some thing like in /usr/src/share/mk/bsd.sys.mk: > > SSP_CFLAGS?= -fstack-protector > CFLAGS+= ${SSP_CFLAGS} > > ??? > > > PS: /usr/ports/UPDATING > "The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all" > should be: > "The default SSP_CFLAGS is -fstack-protector, but -fstack-protector-all" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sat May 5 11:33:39 2018 Return-Path: Delivered-To: freebsd-hackers@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 74D71FAB0E3; Sat, 5 May 2018 11:33:39 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8D586B243; Sat, 5 May 2018 11:33:38 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id j5-v6so8823837wme.5; Sat, 05 May 2018 04:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2N8tbeDILWOE7mUlnlgvSOCsGE+aiTq9X//v0noTMv4=; b=P4Nj7UWAT9IrkQrgMgKq7b9u2IgnH1ZqM4pAc2oaO/NEersGSeMhDZfImUBxjMZtN2 FOSTvJ3c8wBsysl7lkmJBuHXj6sNnpiuHkH09ISYQeeHab98/1Wyxdy+9qKQ0+viuxma o1Ivi5gwd5XoPLYHpWw8M4f7eVY6alhgYHRt5oV1rA3u2IFsi+WVwL6mEWpXUE7+epxi 5Fyoxawf0wC9xWY18XhE4wr1xmgGwrPCl847B8NemllO+vAJeAlysevNPPUxY4vQsgdL y/6w2mgbUwOqLixZcrEnIh41Z+aaADBrFcwzvJniBdgEx+2VztT/71ryDMbnYLlgWKpd k+lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2N8tbeDILWOE7mUlnlgvSOCsGE+aiTq9X//v0noTMv4=; b=GSbsn2EZLH5S5zF7DjHZaTdTLmRrp1wVos1fa3KDFbm4lno+KwDUSMw0qg6FwWKK6t MhtRLmi4N9LcW6iaWelhc1nZpR+Yby5uCnB8saKS8+JNaDyk+5muyEAnZoetNM27++Ji Eq1mEPSlmUJNOYOHypbRKUYJWD6GWXvO1JrN19RyVFuH9sV/DOAgPoRtYZn4E43AYyjJ q8fgOobeQm9KXuuQgqts4g32//h5OAkNWhCiLxWwuFOkLH3EAYvLwMkbJUYwAbDz6UWB bfOYoFuXJqTIfx/nvq8oKbFeT1N+N7fBVi58wv3O4WowlttE39oQiLsxIWH1I2v5iNPK siKw== X-Gm-Message-State: ALQs6tDvnxrNWgQt0LYD4OrZjIPEM+uTccQr2Mlcm0T/PuxWJ3Thq49R mtPOorhpQFG+2iSzVEIA3+UpyS1h X-Google-Smtp-Source: AB8JxZpmxqRp5FcuUkrSP0yTjXu+0zmfp2YTEHc924unQfO6WIAPTTRNXLvDE7PhGlvejMPnHZ2rYQ== X-Received: by 2002:a50:9ea3:: with SMTP id a32-v6mr37267462edf.78.1525520017232; Sat, 05 May 2018 04:33:37 -0700 (PDT) Received: from localhost ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id q6-v6sm4228279edh.9.2018.05.05.04.33.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 05 May 2018 04:33:36 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 5 May 2018 14:33:35 +0300 To: bryn1u85 Cc: freebsd-current@freebsd.org, FreeBSD Hackers , bdrewery@freebsd.org Subject: Re: SSP_CFLAGS for kernel Message-ID: <20180505143335.1091d70a@gmail.com> In-Reply-To: References: <20180505035931.33120d74@gmail.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 11:33:39 -0000 On Sat, 5 May 2018 12:38:37 +0200 bryn1u85 wrote: > Don't touch src.conf I want to buils kernel and system with SSP too. > Entry for make.conf should looks like below: > > WITH_SSP_PORTS=YES > > SSP_CFLAGS=-fstack-protector-all > > SSP_CXXFLAGS=-fstack-protector-all SSP_CXXFLAGS does not used in system and ports, at least on 11.2. From owner-freebsd-hackers@freebsd.org Sat May 5 18:55:47 2018 Return-Path: Delivered-To: freebsd-hackers@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 B20FCFB6ABC; Sat, 5 May 2018 18:55:47 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D9E06BD59; Sat, 5 May 2018 18:55:47 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x236.google.com with SMTP id j7-v6so15141905vkc.9; Sat, 05 May 2018 11:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Hx3DBbVHoQmzjlr0nTwPjwsGb7hgLR4U08gUae8ngro=; b=FzZzcYYCL+KHJC3/eWWQ4lWB4R3rcEyQh3YjpQvGA6McvxnMhYgDDdANLdaQDo8ry2 maB+eTwwWm56llNURYleJX46Beywak4k1hbjdM7/rZ7+nfSnEZgoAfHclDRWWxHsG+XY 3hk/bhW2Loxa84oStDf+MZZu0AiGVd/m4s4ce03oeJf085J7hwLk92pDlBYI3/tTCkgC asaOJju3uqK8QAzkOFsvtgw6Y7KX2IlThx4CI7+ThC/78BLRdCCgOSpHQXX0/XLubkDw eC+NBwoxtSQgnlJDyzY5Vnaf4zL2bHIApVTLjBMSYLI6ozuH/Z1n5TdGkMHT0K3nvRPA uQqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Hx3DBbVHoQmzjlr0nTwPjwsGb7hgLR4U08gUae8ngro=; b=fZi16OEYUZQGTOcPtNBGIDKL6g6RF2n8F9G5dIazW25rttQ6607FlGVijaA6wWhbxJ 4dBM1aycGRcTAeoWYJU7phdydgYndkicF+oE5ZuW7imBMBl7Zq4WCzoi6SgzixE/EWoz Jf5N65VRq10jPWH+BglUvzfmfxMvXt/xxA3IFWFLcBjmK6ZnyAl7Gn/+JdvMVCZIPUXt 2JEQopA4v3rYnPjnM0rmaJLUKUSIjp1ejQgTh+LtjXJcJxNQxgDCSCmy6qdt67Q134Ad Kkqf0uMLPjFBz/r5zkSK5Sjd/621HX5PfGh6vl1046hU645Z+gc8Tpq7asDfWQFe6Htr lLjg== X-Gm-Message-State: ALQs6tDZ678xwXI8CxA1zqyc7c6qUNH/weP2B1itRg5jjtE4FXXRZuxa A8D31dZZWx8lmkZuvHpQ1tL4GVtcm25N3y5tetw= X-Google-Smtp-Source: AB8JxZpsYazEnfZIq9HXBzrp3cJ0/ieBEwauzhGffko0PWwX2V4KP/UPAh6zRV5/RJ6yX0+1zB6/+KvIXdv4hz9LFNc= X-Received: by 2002:a1f:5cca:: with SMTP id q193-v6mr27347962vkb.45.1525546546493; Sat, 05 May 2018 11:55:46 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.81.15 with HTTP; Sat, 5 May 2018 11:55:45 -0700 (PDT) In-Reply-To: <20180505143335.1091d70a@gmail.com> References: <20180505035931.33120d74@gmail.com> <20180505143335.1091d70a@gmail.com> From: Kevin Oberman Date: Sat, 5 May 2018 11:55:45 -0700 X-Google-Sender-Auth: sHTPsTtUvvfWkbn4V2d945S_qXE Message-ID: Subject: Re: SSP_CFLAGS for kernel To: Rozhuk Ivan Cc: bryn1u85 , FreeBSD Current , FreeBSD Hackers , Bryan Drewery X-Mailman-Approved-At: Sat, 05 May 2018 20:14:22 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 18:55:48 -0000 On Sat, May 5, 2018 at 4:33 AM, Rozhuk Ivan wrote: > On Sat, 5 May 2018 12:38:37 +0200 > bryn1u85 wrote: > > > Don't touch src.conf > > I want to buils kernel and system with SSP too Not relevant. /etc/make.conf definitions are applied to ALL make operations and that includes kernel and module building. /etc/src.conf definitions are only applied to the kernel, modules, and ports. When src.conf was created, it was explicitly NOT intended that the file be used for building ports, but someone has changed that. It probably should have been used for ports that built kernel modules, but not any others, but that is not the case. >From bsd.port.mk: # We prefer to pass MK_*=no but it was only supported after a certain # revision. Passing WITHOUT_* may conflict with a make.conf or src.conf's # WITH_* value. Note that ports *do* pull in src.conf. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683