From owner-freebsd-arm@freebsd.org Sun Jun 24 02:57:19 2018 Return-Path: Delivered-To: freebsd-arm@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 A9B8F1012779 for ; Sun, 24 Jun 2018 02:57:18 +0000 (UTC) (envelope-from pcrilly@goodgas.com.au) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 30C2274A4F for ; Sun, 24 Jun 2018 02:57:17 +0000 (UTC) (envelope-from pcrilly@goodgas.com.au) Received: by mail-pg0-x22e.google.com with SMTP id m5-v6so4582857pgd.3 for ; Sat, 23 Jun 2018 19:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=goodgas-com-au.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=KRHG4ag+qCKX7wfWRvsec3aLw0LftJ0odta8L/Zzm3A=; b=VoW+ewHBT0Oo24TxnRqoKClJZlOY0Ik27EijgPZdSADdlvMhDMY2j3emdFdLQg3DDl rAQf59dUnHNxzUXbMJqKvcXeWQi0waHw0rabcXgUdnleRLP4RotXrIK2KK/ZoP3asogk yBkTxB/51EWxDeTiTc7njzXW1/Rbs/1uyvjK6fNi4B87pmSP8zJmKb/j2UF6NtDKHE/a N5A2eDeR5A+nIrjQnKwEbqjWm5hJZLEQx94McfEUsOk0NIX0B8UIKOi6NyYTlm1Au9IG uIt56AUgRhR/L5PlONNeB9RfTvRGfm+o6LGDw45hFsW3S8+8CbPZwu+I55JooeTA92KJ v2AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=KRHG4ag+qCKX7wfWRvsec3aLw0LftJ0odta8L/Zzm3A=; b=Vpx+mNWvoBsgE4UN8I1as56aBcRH9IJkcRvJhxVNCzv7X+qCH7/zszkEqv+fEWmloA p0/AuCq8bBSoNuLoUgaQkeSc2039/RjbkCMYdVtn5PY5ueGbd8QYIEXQ/16TpASU1pir srT8v9bLNOslatCUOd/x0ttq3WXkLWlw0P0UgFZxxQtye5j0Emb1yR52fBfWVT80XLEg jDcJWKtqzjmkrEAEAwDigpDv6uKQM85r3FkADpBRx5c7FRmG8fQZBXO3m1TSAWIhXmYA pt8Z14I+NnLG80WCwwXKbpYuoY4VXHS6UxXV3K7knmuwBkI70VbxcSpjyjhUzRRx+WZi tJcA== X-Gm-Message-State: APt69E2pOCH2y/aew9ty3yZ3OCPeLIykDSO9A4eWbSCXIIwRsmCjizb1 GbMvVxxOrk8oV4O4svMPSgGJkNEQ X-Google-Smtp-Source: ADUXVKIl/EgvDPzXJ+9Y9bmi6h9bMKF9VqrpImpvufvdQFkpSFH+tAIG2JCFJdkL3Wte65V6jiTSqA== X-Received: by 2002:a62:3d15:: with SMTP id k21-v6mr332540pfa.61.1529809035856; Sat, 23 Jun 2018 19:57:15 -0700 (PDT) Received: from [192.168.0.103] ([120.29.52.133]) by smtp.googlemail.com with ESMTPSA id y2-v6sm537611pfa.43.2018.06.23.19.57.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jun 2018 19:57:15 -0700 (PDT) To: freebsd-arm@freebsd.org From: Patrick Crilly Subject: Status of FreeBSD CAM/MMC/SDIO? Message-ID: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> Date: Sun, 24 Jun 2018 12:57:10 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 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.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 02:57:19 -0000 I was wondering if anyone knew what the current state of CAM/MMC/SDIO driver for Raspberry Pi is? I followed this link https://wiki.freebsd.org/SDIO and checked out FreeBSD current. I build a kernel using the GENERIC-MMCCAM conf file. dmesg produced the following regarding SDIO - > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to > PROBE_SDIO_RESET > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET > (mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: > 00000000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT > (mmcprobe0:sdhci_slot0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 > 00000000 00000000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_INIT to > PROBE_SEND_APP_OP_COND The output from camcontrol is > root@generic:~ # camcontrol devlist -v > scbus0 on sdhci_slot0 bus 0: >   at scbus0 target 0 lun 0 > (pass0,sdda0) > scbus-1 on xpt0 bus 0: > <>                                 at scbus-1 target -1 lun ffffffff > (xpt0) Thanks, Patrick. -- "With great power comes great electricity bill" From owner-freebsd-arm@freebsd.org Sun Jun 24 05:00:17 2018 Return-Path: Delivered-To: freebsd-arm@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 7358410177EE for ; Sun, 24 Jun 2018 05:00:17 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 01CFA79451 for ; Sun, 24 Jun 2018 05:00:17 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-it0-x233.google.com with SMTP id p185-v6so7981440itp.4 for ; Sat, 23 Jun 2018 22:00:16 -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=8fpL8QOyByBF4kycCRCQlFyQzMtVc3uDfMswEW3LsFw=; b=anBv5S95BqWrOydWAdi0dkYE4zQO+Y2dkMCcM2XnUpCfdVEgpFkyOOxuImscIfBXj/ snKzSHKKD2gHHu2aBdZrcwkXy+Gznr8dwBxfEKZEpJpGfMNWCQQK7VwIM2ro98Zld5io dsf7rbmOUh4/sMvxx8rphQr31rdmCfkZp9tWt6AibI4f8POzs44Ckq9S8qKILgGpp9GC 7SGYdEI146LEHqENvo96V/SYoSheNEehSIAZqq5x6i7jfiJgpnDHeBDsedawbFkz9Yxd qxjvNYAhcAgwpJl30kH0cnizsFfWgRNF48AzVgPbn+jkC71ABkvCUujJyGDCebdr+jvz 9DfQ== 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=8fpL8QOyByBF4kycCRCQlFyQzMtVc3uDfMswEW3LsFw=; b=Ed9Sq/UWf2yuc4GixZO3ToqseAAb/RAJJ1P3u73dZQjZQpyanjqhJ+v0e2Ef2++LYf +AlSURH7z71Gk08hf3i3fOl5Resj3tuk11Yj/1oozPwB3MsnDqEB7m9PMn8z8WHl4oZr riGIytLcNQJMYILzavmq6XVPBL3bISiGBCPskgbQnZKiyxATvdT2WApNkz6wS1BZ6Or9 uBvqNqDChI1qk79eoFf90FAOReeRc1ciYEfywQhnqG/bVH90Y6xr5sirjMhG2npO5/Gd ImDzv5oVUa86kVvhWtq20L4NsfoTNMMCOqOO30dxzskgz3KeW8bLTFToEPAcpitBva9p XYzQ== X-Gm-Message-State: APt69E3egKqmf0d5S1NvcUyqxmC65txDYABNlqoGa1LC+Ko8pTCh/lYf PYmOsEQZZ/3uL4SLoshH6C+8YknDYfbFC67ea4M9sw== X-Google-Smtp-Source: ADUXVKIDPOrwW8I/4FI5EWPWxB4fwY0tV/yYcFOJgcGnk9za0U9KDxRMjA/1MdDKsuoE12YvPAsdwHj1Z0JEt1cdhcQ= X-Received: by 2002:a02:84cd:: with SMTP id f71-v6mr5987943jai.42.1529816416501; Sat, 23 Jun 2018 22:00:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:510b:0:0:0:0:0 with HTTP; Sat, 23 Jun 2018 22:00:16 -0700 (PDT) In-Reply-To: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> References: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> From: Russell Haley Date: Sat, 23 Jun 2018 22:00:16 -0700 Message-ID: Subject: Re: Status of FreeBSD CAM/MMC/SDIO? To: Patrick Crilly Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 05:00:17 -0000 On Sat, Jun 23, 2018 at 7:57 PM, Patrick Crilly wrote: > I was wondering if anyone knew what the current state of CAM/MMC/SDIO > driver for Raspberry Pi is? > > I followed this link https://wiki.freebsd.org/SDIO and checked out > FreeBSD current. > I build a kernel using the GENERIC-MMCCAM conf file. > > dmesg produced the following regarding SDIO - > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET >> (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET >> (mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: >> 00000000 >> (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT >> (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT >> (mmcprobe0:sdhci_slot0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 >> 00000000 00000000 >> (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_INIT to >> PROBE_SEND_APP_OP_COND >> > Just an uneducated guess: the zeros may indicate a missing dts file entry, or some other error in the Flattened Device Tree? I'd be interested to know the revision you're using > > The output from camcontrol is > > root@generic:~ # camcontrol devlist -v >> scbus0 on sdhci_slot0 bus 0: >> at scbus0 target 0 lun 0 >> (pass0,sdda0) >> scbus-1 on xpt0 bus 0: >> <> at scbus-1 target -1 lun ffffffff >> (xpt0) >> > > Thanks, > Patrick. > > -- > "With great power comes great electricity bill" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sun Jun 24 06:34:05 2018 Return-Path: Delivered-To: freebsd-arm@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 A8EAB101B4F6 for ; Sun, 24 Jun 2018 06:34:05 +0000 (UTC) (envelope-from pcrilly@goodgas.com.au) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 14C377C1C0 for ; Sun, 24 Jun 2018 06:34:04 +0000 (UTC) (envelope-from pcrilly@goodgas.com.au) Received: by mail-pg0-x229.google.com with SMTP id m5-v6so4692259pgd.3 for ; Sat, 23 Jun 2018 23:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=goodgas-com-au.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=E9a70y1f/k50RePVqnYC7ythK5LtazlgCq6n6/fdhi8=; b=bRKW36Zl0dxzPsKV1Pu8b3g9shELWb9YfdP9TZnaUixDijSozrReJ3ubbxK+dHpmju VDZNxJJajrlR/1JLX33KFR9ko6/m9PB4hciFL10uY9vPZ5qRKDTsGj+bYrUL92BuzYfP GG1WuaIWn3u0+pMhjidgFcYL0cOuZMCKpGG3Zu2yqz+7SF5Jd7208Ulqo7YSw9WZHNUg IFDgaUAU2xWuI75ptDa0Fqqrj2fx5LT74DbxAddxxcwbQAvoOHhJbs3GrXBezVOos71u Kc9o3PFCN5syDzyj4iuztQHvRA8+mfCkdxFU6vEEscYC5+EtrNCogD1qULHKrj4rIcUF uGBg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=E9a70y1f/k50RePVqnYC7ythK5LtazlgCq6n6/fdhi8=; b=HLDIlvDkxuxMZ7mlvnFec6Nu+nGgtrWb2OImMk2+oStiC9qKcut61kFAW5rh+5z15d +rTJY/kMDyzJYbefnqgRd1kqppwczujkGoDp/6pcOHfaOx/H5LunmHbM5VUIWc8ZVoOI Oq88WafZ4gVQ0cPkvWlH+NAUWoYT/NFfFC4BozEPiWfPBD4vtIUU8ui3eTLc+ET1pbS+ nOJytrV9TJ8jBgEHLrASZb3G+/V39jEbcW6JVMtWxGH51afuOpJJrulGTD7JfOQKaD27 uYh4UFL4TVQVPxmV/z6CuG0gD31h47Pr8m4cHekKUCStPOoytIfqqISqnFarUwUL7md6 Onkg== X-Gm-Message-State: APt69E0gslxQExIwG4rdO0ggl/4QoyfO9WSpOWvH4X1MUaUU74eeFeAS ycmHzNhbWWUBw1eFwxoeGkX73Z5m X-Google-Smtp-Source: ADUXVKJqK76ao/+drrBqYXr50NnICyFpqI+fi/S62f0kX6EkgRf3olgVl2U1xhqNZTFuUWpXA2m+vg== X-Received: by 2002:a63:b305:: with SMTP id i5-v6mr6662265pgf.370.1529822043438; Sat, 23 Jun 2018 23:34:03 -0700 (PDT) Received: from [192.168.0.103] ([120.29.52.133]) by smtp.googlemail.com with ESMTPSA id c19-v6sm17162637pfn.182.2018.06.23.23.34.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jun 2018 23:34:02 -0700 (PDT) Subject: Re: Status of FreeBSD CAM/MMC/SDIO? To: Russell Haley Cc: freebsd-arm References: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> From: Patrick Crilly Message-ID: Date: Sun, 24 Jun 2018 16:33:57 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-AU Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 06:34:06 -0000 On 24-Jun-18 3:00 PM, Russell Haley wrote: > > > On Sat, Jun 23, 2018 at 7:57 PM, Patrick Crilly > > wrote: > > I was wondering if anyone knew what the current state of > CAM/MMC/SDIO driver for Raspberry Pi is? > > I followed this link https://wiki.freebsd.org/SDIO and checked out > FreeBSD current. > I build a kernel using the GENERIC-MMCCAM conf file. > > dmesg produced the following regarding SDIO - > > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to > PROBE_SDIO_RESET > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET > (mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL > register: 00000000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to > PROBE_SDIO_INIT > (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT > (mmcprobe0:sdhci_slot0:0:0:0): SDIO_INIT: error 1, 00000000 > 00000000 00000000 00000000 > (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_INIT to > PROBE_SEND_APP_OP_COND > > Just an uneducated guess: the zeros may indicate a missing dts file > entry, or some other error in the Flattened Device Tree? > > I'd be interested to know the revision you're using I downloaded this snapshot build for Raspberry Pi 3 - FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180605-r334665.img.xz and loaded it onto a SD card. I then built the kernel using the source from current and the GENERIC_MMC conf file. I built the kernel natively, since I didn't have a cross build machine setup. I did just notice there's some updated snapshot builds, so will give them a try. I realise the SDIO drive is very much work in progress. Hoping someone might be able to say where things are at. > > The output from camcontrol is > > root@generic:~ # camcontrol devlist -v > scbus0 on sdhci_slot0 bus 0: >   at scbus0 target 0 > lun 0 (pass0,sdda0) > scbus-1 on xpt0 bus 0: > <>      at scbus-1 target -1 lun ffffffff (xpt0) > > > Thanks, > Patrick. > > -- > "With great power comes great electricity bill" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > "freebsd-arm-unsubscribe@freebsd.org > " > > -- "With great power comes great electricity bill" From owner-freebsd-arm@freebsd.org Sun Jun 24 14:28:35 2018 Return-Path: Delivered-To: freebsd-arm@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 B64F7100193F for ; Sun, 24 Jun 2018 14:28:35 +0000 (UTC) (envelope-from russ.haley@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 1D2128BBC3 for ; Sun, 24 Jun 2018 14:28:35 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-it0-x244.google.com with SMTP id 128-v6so2863323itf.1 for ; Sun, 24 Jun 2018 07:28:35 -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=8fGz0T3VWUWlVBCQ5Xfrr+nA3X38ZRELO6xJ/I4a9sg=; b=mwWMlVpWkOx7Me+8OiKLPOlEdNsNMJBawpMQvKn2JggolnSK71QCu0XfMSDSq4YY2d DLyiN0HGe4/3XjeAFDUd9sjLthBhUOC3Ocei6ATD6FDQ1iiWVXZv6pjIPrcWJKr3/iaI 5SCJsLPwgC/U+7dx7F/ukZl/ZGhuTy5XIQWQ7JwxzxmlXLLac3TRovCmOcma1PvvcLnF 323IPMB4JEkkfnCBbOL+wCqZrLxbMaDnwGZQL6eAVu+Cv0C1D7aghOGBdLFgHt21zMYj 58K5vjQcrvhg0+AvMg5ZY/jFwTzeAmy8QkB0tegA4MREx+ygK9JV/z9KCFN2GqaI1JH8 CBeA== 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=8fGz0T3VWUWlVBCQ5Xfrr+nA3X38ZRELO6xJ/I4a9sg=; b=YkD0P6WgwhYslV7nJDH2eSjBxO6CaHp84qRjXKAjZJ8zlvxpPmbZgtIPy+SOQ5tP1e YhzMxthDeubVRkyCKmFs7d3Fqe0CVCHqPSZiS0TF70BDQB4v5g/RMb/QNlUZKo24XpSV lhJ6WBo+ZIILHouroHtpPmUF0HwW5ZXlpTcizDE2KeoczZAfzE+N/WWOQAAwmOFRWNx4 HiBibAmHPz2BBbb4Pl7cucbxdAWocmlXAdS0EFzmCTRcqefbv1Obk9DXhJhYlvmQL0qr t/yQpoC3qLi8VL4pKsuRyKy9Yc99CEnmNvDBUg6Dvu1sXirDeIsY8Riw8hspPvXs9/j/ khWg== X-Gm-Message-State: APt69E23q7weRjjFOBOsz8Cf203N6NzCSqW4uVuYAp0pcSMPi0xTDI4j aUSDm9oaktZyDXGUMc4U0rYc4xYctfuWl8THBdOJ2A== X-Google-Smtp-Source: ADUXVKKTR1Fzi3es4XnD4K+xyqmM0ubVyuI5S5m/9jfx4PKy/2GkHgBUDBiYFVkArYLIDZq+L9vGicvBI9PBE9L0JTk= X-Received: by 2002:a24:5f84:: with SMTP id r126-v6mr6839925itb.22.1529850514519; Sun, 24 Jun 2018 07:28:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:510b:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 07:28:34 -0700 (PDT) In-Reply-To: References: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> From: Russell Haley Date: Sun, 24 Jun 2018 07:28:34 -0700 Message-ID: Subject: Re: Status of FreeBSD CAM/MMC/SDIO? To: Patrick Crilly Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 14:28:36 -0000 On Sat, Jun 23, 2018 at 11:33 PM, Patrick Crilly wrote: > On 24-Jun-18 3:00 PM, Russell Haley wrote: > > > > On Sat, Jun 23, 2018 at 7:57 PM, Patrick Crilly > wrote: > >> I was wondering if anyone knew what the current state of CAM/MMC/SDIO >> driver for Raspberry Pi is? >> >> I followed this link https://wiki.freebsd.org/SDIO and checked out >> FreeBSD current. >> I build a kernel using the GENERIC-MMCCAM conf file. >> >> dmesg produced the following regarding SDIO - >> >> (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to >>> PROBE_SDIO_RESET >>> (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET >>> (mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: >>> 00000000 >>> (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT >>> (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT >>> (mmcprobe0:sdhci_slot0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 >>> 00000000 00000000 >>> (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_INIT to >>> PROBE_SEND_APP_OP_COND >>> >> Just an uneducated guess: the zeros may indicate a missing dts file > entry, or some other error in the Flattened Device Tree? > > > I'd be interested to know the revision you're using > > > I downloaded this snapshot build for Raspberry Pi 3 - > FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180605-r334665.img.xz and > loaded it onto a SD card. > > I then built the kernel using the source from current and the GENERIC_MMC > conf file. I built the kernel natively, since I didn't have a cross build > machine setup. > > I did just notice there's some updated snapshot builds, so will give them > a try. > > I realise the SDIO drive is very much work in progress. Hoping someone > might be able to say where things are at. > I can't speak to the details, and maybe Ilya will speak up, but I know development is active as Illya Bakulin made some commits recently. Udit Argawal is doing some performance testing on Beagle Bone Black and porting SDIO it to RTEMS, but he was unable to build against CURRENT and is building against Ilya's git branch. He was also getting exceptions early in the boot process when building with head. However Udit's problem was with a bad lock/mutex not the registers (hence my question about your revision). Udit's blog is here: http://uditagarwal.in. He was about to test building against head but was hung up waiting on me (hopefully I unblocked him yesterday). I was considering to set up a website to server out SDIO enabled kernels as I've got a hearty server to play with. Perhaps I'll put a little effort into that tonight. I can build kernels in about 5 minutes, compared to your... week? Hope that helps a little, Russ > > > > >> >> The output from camcontrol is >> >> root@generic:~ # camcontrol devlist -v >>> scbus0 on sdhci_slot0 bus 0: >>> at scbus0 target 0 lun 0 >>> (pass0,sdda0) >>> scbus-1 on xpt0 bus 0: >>> <> at scbus-1 target -1 lun ffffffff >>> (xpt0) >>> >> >> Thanks, >> Patrick. >> >> -- >> "With great power comes great electricity bill" >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > > > -- > "With great power comes great electricity bill" > > From owner-freebsd-arm@freebsd.org Sun Jun 24 15:03:40 2018 Return-Path: Delivered-To: freebsd-arm@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 8CAFF100254B for ; Sun, 24 Jun 2018 15:03:40 +0000 (UTC) (envelope-from dev.madaari@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 02C428CB00 for ; Sun, 24 Jun 2018 15:03:40 +0000 (UTC) (envelope-from dev.madaari@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id x6-v6so6557391wmc.3 for ; Sun, 24 Jun 2018 08:03: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=G977kgdYSCnYbTNFmblF6o3wjhBUVV4wpHlMSp1GAXI=; b=R607ss06IZfPw6jy0XqwksTOMZC8XxkZWqodMRiGTsn3+R2gumMc2FzNbigYgRLMsc JSjEB2upjlKXN9hHUvzx+u+r6OpGgKJE8z1iVgxDA/OFsdvzw0mCKTxBDS5O4B+b1p9H SvMrT8NGkQ6PgYx0GkAAgl/miuyrBCRVFOYYym7D3xOc3OeeV0DnLVfbVk4kuZfyNPNF pEvUXqGBoYhVNzRDGt43/VOkiq1EhqciFcsyajTj/IDuqWoljGz3mI0O5zdIOYIK05t1 CAtFdLjMen7169aIUouTqSN+QuhHRICPM9dh2+w76eCXsn7AjyqF3/79lPQr0mW9KMwX uokA== 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=G977kgdYSCnYbTNFmblF6o3wjhBUVV4wpHlMSp1GAXI=; b=HO82wJFaul6DrEP70wC+59tnQd5deVQwsUp4r92JV8yRGxv+rhTsyaDCy088OC6aQm jjnri4+CWdsWt84ReVdIB2hn7q5c3BWs+CwENqZMqKeKq8fA8/zHWSfRuEz8ty8x6NUj 47DOYw8ha6LIP5mqkgjJNwe152a/IHpKuZ6fHtdFtyhcYmuQDZEG7dtitBWzlUeTkFmO fbSENHzLJXd28kDWjdde6uKQ8bSmZLzGsNh8G10teQMcc5UoHV+nXSPdSr9zSgnZUoJk x4wej93ytrB9RnkZxxqLzg2ofXOIvfgoUoCsvlE/G+Cb0U2c/r9mXBBrGncyl1jRk098 N6mg== X-Gm-Message-State: APt69E0tTvdwrOpR1UyGw2vZr+uqwpG2tyrBcTJAY3xbwYwtp0z54vj7 KAJ9Fqh5nwOxSEwi+tPpB3PlyRHGjta7Xt5Hk5Y= X-Google-Smtp-Source: ADUXVKIf46sFdWQtKfCkeNG/Wo7uvf0iIzPRwYiucXymQQThryg68QEXBnX/FFXpfQjbWo19PFcuwjDbZadQZFSup8k= X-Received: by 2002:a1c:d8:: with SMTP id 207-v6mr6378300wma.99.1529852618793; Sun, 24 Jun 2018 08:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:7e8e:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 08:03:37 -0700 (PDT) In-Reply-To: References: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> From: Udit agarwal Date: Sun, 24 Jun 2018 20:33:37 +0530 Message-ID: Subject: Re: Status of FreeBSD CAM/MMC/SDIO? To: Russell Haley Cc: Patrick Crilly , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 15:03:40 -0000 Hi, On Sun, Jun 24, 2018 at 7:58 PM, Russell Haley wrote: > On Sat, Jun 23, 2018 at 11:33 PM, Patrick Crilly > wrote: > > > On 24-Jun-18 3:00 PM, Russell Haley wrote: > > > > > > > > On Sat, Jun 23, 2018 at 7:57 PM, Patrick Crilly > > wrote: > > > >> I was wondering if anyone knew what the current state of CAM/MMC/SDIO > >> driver for Raspberry Pi is? > >> > >> I followed this link https://wiki.freebsd.org/SDIO and checked out > >> FreeBSD current. > >> I build a kernel using the GENERIC-MMCCAM conf file. > >> > >> dmesg produced the following regarding SDIO - > >> > >> (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to > >>> PROBE_SDIO_RESET > >>> (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET > >>> (mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: > >>> 00000000 > >>> (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to > PROBE_SDIO_INIT > >>> (mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT > >>> (mmcprobe0:sdhci_slot0:0:0:0): SDIO_INIT: error 1, 00000000 00000000 > >>> 00000000 00000000 > >>> (mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_INIT to > >>> PROBE_SEND_APP_OP_COND > >>> > >> Just an uneducated guess: the zeros may indicate a missing dts file > > entry, or some other error in the Flattened Device Tree? > > > > > > I'd be interested to know the revision you're using > > > > > > I downloaded this snapshot build for Raspberry Pi 3 - > > FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180605-r334665.img.xz and > > loaded it onto a SD card. > > > > I then built the kernel using the source from current and the GENERIC_MMC > > conf file. I built the kernel natively, since I didn't have a cross build > > machine setup. > > > > I did just notice there's some updated snapshot builds, so will give them > > a try. > > > > I realise the SDIO drive is very much work in progress. Hoping someone > > might be able to say where things are at. > > > > I can't speak to the details, and maybe Ilya will speak up, but I know > development is active as Illya Bakulin made some commits recently. Udit > Argawal is doing some performance testing on Beagle Bone Black and porting > SDIO it to RTEMS, but he was unable to build against CURRENT and is > building against Ilya's git branch. He was also getting exceptions early in > the boot process when building with head. However Udit's problem was with a > bad lock/mutex not the registers (hence my question about your revision). > Udit's blog is here: http://uditagarwal.in. He was about to test building > against head but was hung up waiting on me (hopefully I unblocked him > yesterday). > > I tested the recent changes in the MMCCAM stack form CURRENT yesterday, and the SDIO driver was working perfectly(I tested it on BBB). AFAIK, Currently, SDIO driver should be able to detect and list all MMC/SD/SDIO cards and that should be visible by camcontrol devlist. However, if one intended to access wifi(as in case of Rpi3) that is something still to be done, it's driver isn't ready yet. > I was considering to set up a website to server out SDIO enabled kernels as > I've got a hearty server to play with. Perhaps I'll put a little effort > into that tonight. I can build kernels in about 5 minutes, compared to > your... week? > > Hope that helps a little, > Russ > > > > > > > > > > >> > >> The output from camcontrol is > >> > >> root@generic:~ # camcontrol devlist -v > >>> scbus0 on sdhci_slot0 bus 0: > >>> at scbus0 target 0 lun 0 > >>> (pass0,sdda0) > >>> scbus-1 on xpt0 bus 0: > >>> <> at scbus-1 target -1 lun ffffffff > >>> (xpt0) > >>> > >> > >> Thanks, > >> Patrick. > >> > >> -- > >> "With great power comes great electricity bill" > >> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >> > > > > > > -- > > "With great power comes great electricity bill" > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sun Jun 24 20:52:43 2018 Return-Path: Delivered-To: freebsd-arm@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 4355E100EF70 for ; Sun, 24 Jun 2018 20:52:43 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 D20117A28B for ; Sun, 24 Jun 2018 20:52:42 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fXBzs-0007ne-S9; Sun, 24 Jun 2018 22:52:34 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Warner Losh" , "Konstantin Belousov" Cc: freebsd-arm@freebsd.org Subject: Re: panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at /usr/src/sys/kern/sched_ule.c:2137 References: <20180601154153.GA62632@www.zefox.net> <20180602091606.63a1ab37.freebsd.ed.lists@sumeritec.com> <20180602150549.GA68197@www.zefox.net> <20180602193255.GA68908@www.zefox.net> <20180602210450.GK3789@kib.kiev.ua> Date: Sun, 24 Jun 2018 22:52:32 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20180602210450.GK3789@kib.kiev.ua> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 66f4fda096222dd2b2010deb1ce817c5 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 20:52:43 -0000 On Sat, 02 Jun 2018 23:04:50 +0200, Konstantin Belousov wrote: > On Sat, Jun 02, 2018 at 02:39:00PM -0600, Warner Losh wrote: >> On Sat, Jun 2, 2018, 1:32 PM bob prohaska wrote: >> >> > On Sat, Jun 02, 2018 at 09:14:18AM -0600, Warner Losh wrote: >> > > >> > > Do you have r334508? It fixes the OOM falsely triggering. >> > > >> > At the moment sources are at 334456, world and kernel are at >> > 334276. >> > >> > Might it be feasible to stop the present buildworld, update >> > sources and then try to build a new kernel before building >> > world? >> > >> >> That's recent enough that you should be fine. There might be an lld vs >> binutils ld issue. There was on i386 recently, but I think it was i386 >> specific. It's a good risk. > > This happens on arm64 ? In fact, try this. > I did not even compiled the change. > > diff --git a/sys/arm64/arm64/swtch.S b/sys/arm64/arm64/swtch.S > index c9843303b1d..4c2c3aca583 100644 > --- a/sys/arm64/arm64/swtch.S > +++ b/sys/arm64/arm64/swtch.S > @@ -165,10 +165,9 @@ ENTRY(cpu_switch) > mov x0, x19 > /* > - * Release the old thread. This doesn't need to be a store-release > - * as the above dsb instruction will provide release semantics. > + * Release the old thread. > */ > - str x2, [x0, #TD_LOCK] > + stlr x2, [x0, #TD_LOCK] > #if defined(SCHED_ULE) && defined(SMP) > /* Spin if TD_LOCK points to a blocked_lock */ > ldr x2, =_C_LABEL(blocked_lock) Hi, this patch was committed in r334851. Thanks for that. I just wanted to note that since I'm running a GENERIC-NODEBUG kernel of 333449 (before the commit) I have not seen the TDQ_LOCKPTR panics anymore. While the RPI3B+ has been compiling quite heavy. So, my question, is it expected that the panic does not occur (or far less) with a -NODEBUG kernel? Ronald. From owner-freebsd-arm@freebsd.org Sun Jun 24 20:58:43 2018 Return-Path: Delivered-To: freebsd-arm@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 1B51D100F658 for ; Sun, 24 Jun 2018 20:58:43 +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 9ABD77A5F7 for ; Sun, 24 Jun 2018 20:58:42 +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 ESMTP id w5OKwU3u092424; Sun, 24 Jun 2018 23:58:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w5OKwU3u092424 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w5OKwUM3092423; Sun, 24 Jun 2018 23:58:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Jun 2018 23:58:30 +0300 From: Konstantin Belousov To: Ronald Klop Cc: Warner Losh , freebsd-arm@freebsd.org Subject: Re: panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at /usr/src/sys/kern/sched_ule.c:2137 Message-ID: <20180624205830.GA2430@kib.kiev.ua> References: <20180601154153.GA62632@www.zefox.net> <20180602091606.63a1ab37.freebsd.ed.lists@sumeritec.com> <20180602150549.GA68197@www.zefox.net> <20180602193255.GA68908@www.zefox.net> <20180602210450.GK3789@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) 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-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 20:58:43 -0000 On Sun, Jun 24, 2018 at 10:52:32PM +0200, Ronald Klop wrote: > On Sat, 02 Jun 2018 23:04:50 +0200, Konstantin Belousov > wrote: > > > On Sat, Jun 02, 2018 at 02:39:00PM -0600, Warner Losh wrote: > >> On Sat, Jun 2, 2018, 1:32 PM bob prohaska wrote: > >> > >> > On Sat, Jun 02, 2018 at 09:14:18AM -0600, Warner Losh wrote: > >> > > > >> > > Do you have r334508? It fixes the OOM falsely triggering. > >> > > > >> > At the moment sources are at 334456, world and kernel are at > >> > 334276. > >> > > >> > Might it be feasible to stop the present buildworld, update > >> > sources and then try to build a new kernel before building > >> > world? > >> > > >> > >> That's recent enough that you should be fine. There might be an lld vs > >> binutils ld issue. There was on i386 recently, but I think it was i386 > >> specific. It's a good risk. > > > > This happens on arm64 ? In fact, try this. > > I did not even compiled the change. > > > > diff --git a/sys/arm64/arm64/swtch.S b/sys/arm64/arm64/swtch.S > > index c9843303b1d..4c2c3aca583 100644 > > --- a/sys/arm64/arm64/swtch.S > > +++ b/sys/arm64/arm64/swtch.S > > @@ -165,10 +165,9 @@ ENTRY(cpu_switch) > > mov x0, x19 > > /* > > - * Release the old thread. This doesn't need to be a store-release > > - * as the above dsb instruction will provide release semantics. > > + * Release the old thread. > > */ > > - str x2, [x0, #TD_LOCK] > > + stlr x2, [x0, #TD_LOCK] > > #if defined(SCHED_ULE) && defined(SMP) > > /* Spin if TD_LOCK points to a blocked_lock */ > > ldr x2, =_C_LABEL(blocked_lock) > > Hi, this patch was committed in r334851. Thanks for that. > I just wanted to note that since I'm running a GENERIC-NODEBUG kernel of > 333449 (before the commit) I have not seen the TDQ_LOCKPTR panics anymore. > While the RPI3B+ has been compiling quite heavy. > > So, my question, is it expected that the panic does not occur (or far > less) with a -NODEBUG kernel? Kernel without INVARIANTS does not have asserts compiled in. From owner-freebsd-arm@freebsd.org Sun Jun 24 21:00:11 2018 Return-Path: Delivered-To: freebsd-arm@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 548AB100F92E for ; Sun, 24 Jun 2018 21:00:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9F9C7A713 for ; Sun, 24 Jun 2018 21:00:10 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 40C3897B8 for ; Sun, 24 Jun 2018 21:00:10 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w5OL0AGY038074 for ; Sun, 24 Jun 2018 21:00:10 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w5OL0APG038067 for freebsd-arm@FreeBSD.org; Sun, 24 Jun 2018 21:00:10 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201806242100.w5OL0APG038067@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 24 Jun 2018 21:00:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 21:00:11 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 220297 | arch(7) rename arm64 to aarch64 respecting `uname 1 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Sun Jun 24 23:10:13 2018 Return-Path: Delivered-To: freebsd-arm@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 9F2951018351 for ; Sun, 24 Jun 2018 23:10:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 017E380C70 for ; Sun, 24 Jun 2018 23:10:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5ONALTc012311 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Jun 2018 16:10:21 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5ONAKYI012310; Sun, 24 Jun 2018 16:10:20 -0700 (PDT) (envelope-from fbsd) Date: Sun, 24 Jun 2018 16:10:20 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180624231020.GA11132@www.zefox.net> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 23:10:13 -0000 I've tried to replicate the RPi3 "run out of swap" experiment after updating source, kernel and world to r335576. Roughly the same things happen: Errors flood the console, when swap usage goes a bit over 80% the machine becomes unresponsive. No sign of the OOM assassin. However, -j4 buildworld got all the way to building libraries. With r334939 it always stopped in cross tools. That seems like a significant improvement in swap usage efficiency. Is this to be expected? What details were captured can be seen at http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/ in case they're of interest. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Mon Jun 25 04:22:52 2018 Return-Path: Delivered-To: freebsd-arm@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 B964C1023786 for ; Mon, 25 Jun 2018 04:22:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-10.consmr.mail.gq1.yahoo.com (sonic307-10.consmr.mail.gq1.yahoo.com [98.137.64.34]) (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 1F03F8A093 for ; Mon, 25 Jun 2018 04:22:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: xnFH40UVM1kV9iMDHF9CEfaTD7Bfy0OaA0MJjpEAMvQEAIM4kLe0MtJAgh2Xd7n y2e60a.XHF2FCUS9ZpQ0bUfL5Vo8VmuVa1ePlkpeHKedpeUyOIYhwIz4YM8fN5uFqrzpxh4FFj0T 8_k6pRFX2WEPl8tPZbiLS376Y6k3xZhgWEcjqNAiAqZlwNnnbCGjMzmx2WRfWBXAr2Ch_bPSJek8 rkA0Tcq0HndsYLyz0ZK3ySwmUAEbTp0C0ZDBzj7wI1hsZ3C8Q0FE.grqJmWk1MvAUGH4rZ96gzGB zBE3OVFAGjgYnQOzrDIaCANXleFeJ8aisNWZiCA81cjwpeZDASQZXE8SSYVmXaPE32j8FPOWFpFS g3tW4aPYADWzPOMjw4eBrLf5cIVOg.Yt.YotCS975DnrSXPM46m0plOiqPaoQijQFWjwQyg9aqyV OjIzquHx_3iVHW0tf0cXF8uvOlvicZWZRKt3Rpsrhf10T.3ZBUVR6.Yig4WpId9joRkWPZ4WNF_V 6UgIhhigO4ezJVFPUz8J8xJ8XCf3oLtRBGC4XgnbO2.1.jI85RcjATYxi12ULd3mvev37o5XFBPn PTu7Bksu3h5LASTlZ7_yqrEdrdLwsNZP_qrR7RAde40I5hs_niX5_JwpKjgj9x6niSR5txuGhIfB h3pO0NDFfqnlIlPeSSBvpw_bH1nSfQvR19wBLROyo.enXrm0ED4.1uJ2ENi.HSpLPcjlTFSa2.JS lcSCN5uFXuGJV0Yd2ciHBMn_uy8zuawsxvHfSG_3ulUa7iQLiwSosZ_Vp76yKdx5aW5vh_t_xPGw Q5ISSGALa5nMWg6KjAKTALIJx3XwKGKBsL6K6ijuabHIXLqWuy9hfzR2OBCLFwaasFTHWnTa7gmn oxOy4PZ5Xem73EwdYksDsZw7ZTfSUxXxuyZfSGU.Mt6k.DkzKFZh0mQ_68bRCnoEMN2PXRUGCoHF usjmbsE_8C8HsUFf1qrlyYRSnSg3Xsw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 25 Jun 2018 04:22:43 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ecf7377f9be98f5e028a56c58a6f3a62; Mon, 25 Jun 2018 04:22:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180624231020.GA11132@www.zefox.net> Date: Sun, 24 Jun 2018 21:22:38 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 04:22:52 -0000 On 2018-Jun-24, at 4:10 PM, bob prohaska wrote: > I've tried to replicate the RPi3 "run out of swap" experiment after > updating source, kernel and world to r335576. Roughly the same things = happen: > Errors flood the console, when swap usage goes a bit over 80% the = machine becomes > unresponsive. No sign of the OOM assassin.=20 >=20 > However, -j4 buildworld got all the way to building libraries. With = r334939 it > always stopped in cross tools. That seems like a significant = improvement > in swap usage efficiency. Is this to be expected?=20 >=20 =46rom the log file: = http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/buildworld.lo= g is the text: --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 299: SYSTEM_COMPILER: Determined = that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 304: SYSTEM_LINKER: Determined = that LD=3Dld matches the source tree. Not bootstrapping a cross-linker. So the cross compiler and cross linker were not built: the existing llvm files were used. It was during building of these that the earlier failures happened in the cross-tools stage as I understand: the other stuff does not require as big of processes, or as big of a maximum-total for -j4 . > What details were captured can be seen at > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/ > in case they're of interest. You are still using the drive that gets the errors ( /dev/da0 ), even if it is not being used for swapping. http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/console shows: _vfs_done():da0d[WRITE(offset=3D51819347968, length=3D131072)]error =3D = 5 g_vfs_done():da0d[WRITE(offset=3D51819479040, length=3D28672)]error =3D = 5 g_vfs_done():da0d[READ(offset=3D59586936832, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) da0d[READ(offset=3D59650965504, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 3950 (sshd) da0a[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D8585216, length=3D4096)]error =3D 5 :24 www kernel: Failed to fully fault in a core file segment at VA = 0x405e6000 with size 0x10000 to be written at offset 0x346000 for = process tcsh Jun 24 13:25:25 www kernel: Failed to fully fault in a core file segment = at VA 0x40c41000 with size 0x10000 to be written at offset 0x981000 for = process tcsh (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted g_vfs_done():da0a[WRITE(offset=3D805568512, length=3D32768)]error =3D 5 g_vfs_done():da0d[READ(offset=3D59580710912, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 3960 (csh) da0d[READ(offset=3D59604205568, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) da0a[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D8585216, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268599296, length=3D16384)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268632064, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268664832, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D289939456, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D377454592, length=3D131072)]error =3D 5 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted g_vfs_done():da0a[WRITE(offset=3D268664832, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D377454592, length=3D32768)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D20709376, length=3D4096)]error =3D 5 g_vfs_done():da0d[R:20 www kernel: Failed to fully fault in a core file = segment at VA 0x40c72000 with size 0x10000 to be written at offset = 0x992000 for process tcsh EAD(offset=3D17179279360, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 817 (sshd) da0d[READ(offset=3D36814438400, length=3D4096)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D51207864320, length=3D32768)]error =3D = 5 g_vfs_done():da0d[WRITE(offset=3D51208126464, length=3D32768)]error =3D = 5 g_vfs_done():da0a[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D8585216, length=3D4096)]error =3D 5 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted g_vfs_done():da0a[WRITE(offset=3D377585664, length=3D8192)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D805568512, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D825851904, length=3D16384)]error =3D 5 g_vfs_done():da0d[READ(offset=3D39456112640, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 646 (getty) da0d[WRITE(offset=3D51818659840, length=3D32768)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D51819053056, length=3D32768)]error =3D = 5 g_vfs_done():da0d[WRITE(offset=3D51819347968, length=3D131072)]error =3D = 5 g_vfs_done():da0d[WRITE(offset=3D51819479040, length=3D28672)]error =3D = 5 g_vfs_done():da0d[READ(offset=3D59651031040, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 817 (sshd) da0a[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D8585216, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268599296, length=3D16384)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268632064, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268664832, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D277078016, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D377454592, length=3D131072)]error =3D 5 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted g_vfs_done():da0a[WRITE(offset=3D377454592, length=3D32768)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D20709376, length=3D4096)]error =3D 5 g_vfs_done():da0d[READ(offset=3D17179312128, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 695 (sshd) da0d[READ(offset=3D39456473088, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 646 (getty) da0d[WRITE(offset=3D51207864320, length=3D32768)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D51208126464, length=3D32768)]error =3D = 5 g_vfs_done():da0a[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D8585216, length=3D4096)]error =3D 5 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0b 3f c0 00 00 80 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted g_vfs_done():da0a[WRITE(offset=3D377585664, length=3D16384)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D805568512, length=3D32768)]error =3D 5 g_vfs_done():da0d[READ(offset=3D39456047104, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D8585216, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268599296, length=3D16384)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268632064, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D268664832, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D277078016, length=3D4096)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D377454592, length=3D131072)]error =3D 5 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 41 80 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain There are examples of > 50 seconds for ms/w: 2 0 0 0 0.0 0 10 53783 0 0 = 0.0 537.8 da0d 5 1 0 0 0.0 1 14 54159 0 0 = 0.0 551.9 da0 3 0 0 0 0.0 0 3 55101 0 0 = 0.0 551.9 da0a There are a lot with > 20 seconds for ms/w, I'll not list them here. Similarly for > 20 seconds for ms/r. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Jun 25 11:50:26 2018 Return-Path: Delivered-To: freebsd-arm@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 3D4AB1009F70 for ; Mon, 25 Jun 2018 11:50:26 +0000 (UTC) (envelope-from abologna@redhat.com) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E105979566 for ; Mon, 25 Jun 2018 11:50:25 +0000 (UTC) (envelope-from abologna@redhat.com) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6584A87928; Mon, 25 Jun 2018 11:50:19 +0000 (UTC) Received: from inaba.usersys.redhat.com (unknown [10.43.2.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 580C0111DCE8; Mon, 25 Jun 2018 11:50:18 +0000 (UTC) Message-ID: Subject: Re: virtio-net issues on aarch64 QEMU/KVM From: Andrea Bolognani To: Mark Rutland , Ruslan Bukin Cc: freebsd-arm@freebsd.org, "Robert N. M. Watson" Date: Mon, 25 Jun 2018 13:50:16 +0200 In-Reply-To: <20180615163512.55o5ldr6dwwl5jdl@lakrids.cambridge.arm.com> References: <1501165794.4378.8.camel@redhat.com> <20170804132950.GA9477@remoulade> <20180615115602.GA29619@bsdpad.com> <20180615161023.GA34414@bsdpad.com> <20180615163512.55o5ldr6dwwl5jdl@lakrids.cambridge.arm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 25 Jun 2018 11:50:19 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 25 Jun 2018 11:50:19 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'abologna@redhat.com' RCPT:'' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 11:50:26 -0000 On Fri, 2018-06-15 at 17:35 +0100, Mark Rutland wrote: > On Fri, Jun 15, 2018 at 05:10:23PM +0100, Ruslan Bukin wrote: > > I committed the fix: > > https://lists.freebsd.org/pipermail/svn-src-head/2018-June/114969.html > > Great; thanks for tackling this! I just tried booting the latest -CURRENT qcow2 image (2018-Jun-18) and I can confirm virtio-net works on aarch64 as well. Thanks for looking into it! Additionally, the issue preventing SMT guests to boot seems to have been fixed too, since I could go all the way to 4 vCPUs whereas I was limited to 1 before :) -- Andrea Bolognani / Red Hat / Virtualization From owner-freebsd-arm@freebsd.org Mon Jun 25 15:12:18 2018 Return-Path: Delivered-To: freebsd-arm@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 7CDB71012F6C for ; Mon, 25 Jun 2018 15:12:18 +0000 (UTC) (envelope-from kibab@zugspitze.bakulin.de) Received: from zugspitze.bakulin.de (zugspitze.bakulin.de [IPv6:2a01:4f8:140:1258::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1ABF080FEB for ; Mon, 25 Jun 2018 15:12:17 +0000 (UTC) (envelope-from kibab@zugspitze.bakulin.de) Date: Mon, 25 Jun 2018 17:12:10 +0200 From: Ilya Bakulin To: Patrick Crilly Cc: freebsd-arm@freebsd.org Subject: Re: Status of FreeBSD CAM/MMC/SDIO? Message-ID: <20180625151210.GA38661@zugspitze.bakulin.de> References: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 15:12:18 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 24, 2018 at 12:57:10PM +1000, Patrick Crilly wrote: > I was wondering if anyone knew what the current state of CAM/MMC/SDIO=20 > driver for Raspberry Pi is? >=20 Hi Patrick, For trying out MMCCAM on Raspberry Pi 3 you need an additional diff: https://reviews.freebsd.org/D14168 This adds a completely new driver, SDHOST, that operates a simplified SDHC controller and uses it to access SD/MMC slot on Rpi3. A full-fledged S= DHC controller is then connected to the SDIO WiFi chip. Then you can use both S= DHC card and SDIO WiFi. As for WiFi module itself, there is no driver for it yet. The work on the d= river has not started, because the prerequisite change https://reviews.freebsd.or= g/D12467 hasn't been merged yet. I'm unable to provide any ETAs on merging that one,= because it's a pretty big architectural change. -- Ilya --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEErEChh/KCfYJWuCXeSiYiySWYIdMFAlsxBkVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD NDBBMTg3RjI4MjdEODI1NkI4MjVERTRBMjYyMkM5MjU5ODIxRDMACgkQSiYiySWY IdOvxQgAkEDJ5TV96EMpTsD7BQ+x0N/INaX7nqFVGfqjzrJP+NAv960w2Ai2DpMh 1reAujeYin58/h1fNfisQLZF2OvYKkN20bi6eUdRj6YCHOmDzrgoZYHoC4tMKjBS 0G7sB/tQ8a67demfVBPnS1JhHzatlNKtodXZwlaKlsWg0VhOmMPNeZ5dJXjVclpT fOBz0juoLSLftr0IyPD7A5OqcZfmT2g33YrruVPG1jMlMPP50h6uZ9iELzatANaG 3FzpgRy82IyjqOhSukNUBu7HdW9xx6QdKrsqt9uIQaBncaszgem95R142P17ZQpA X6hlWjD8iYIjaee7uGVGCvI6/onKNA== =Nibg -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-arm@freebsd.org Mon Jun 25 23:41:47 2018 Return-Path: Delivered-To: freebsd-arm@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 B3C571025086 for ; Mon, 25 Jun 2018 23:41:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67A1872C79 for ; Mon, 25 Jun 2018 23:41:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 7449910AFD2 for ; Mon, 25 Jun 2018 19:41:41 -0400 (EDT) To: freebsd-arm@FreeBSD.org From: John Baldwin Subject: [CFT] Newer kgdb bits for testing Message-ID: Date: Mon, 25 Jun 2018 16:41:40 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 25 Jun 2018 19:41:41 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 23:41:47 -0000 At BSDCan I finally sat down and wrote a FreeBSD/arm kernel target for the ports kgdb (GDB 8.1). It passed simple testing "live" on my little RPi, but I haven't tested it against a vmcore. (In theory cross-debugging a vmcore should Just Work(tm)). I'd like to default FreeBSD/arm to storing the old gdb in /usr/libexec for use by crashinfo, but the ports kgdb needs a bit more testing before we can throw the switch. To build the new kgdb, you can either apply the patches from https://reviews.freebsd.org/D16013 to the devel/gdb port and rebuild the port, or you can build gdb from the 'freebsd-8.1-kgdb' branch of github.com/bsdjhb/gdb.git. One thing in particular I haven't been able to test yet is unwinding across an in-kernel trapframe (for an exception taken while in the kernel for example). It wasn't clear to me from reading the assembly bits in exception.S if I need to pull the PC and LR values from a different offset in struct trapframe for in-kernel trapframes vs traps from userland. -- John Baldwin From owner-freebsd-arm@freebsd.org Tue Jun 26 05:24:44 2018 Return-Path: Delivered-To: freebsd-arm@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 6C95C101016B for ; Tue, 26 Jun 2018 05:24:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C0B2C8007D for ; Tue, 26 Jun 2018 05:24:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5Q5OqR6017812 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Jun 2018 22:24:52 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5Q5OpHR017811; Mon, 25 Jun 2018 22:24:51 -0700 (PDT) (envelope-from fbsd) Date: Mon, 25 Jun 2018 22:24:51 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180626052451.GA17293@www.zefox.net> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 05:24:44 -0000 On Sun, Jun 24, 2018 at 09:22:38PM -0700, Mark Millard wrote: > On 2018-Jun-24, at 4:10 PM, bob prohaska wrote: > > > > I've tried to replicate the RPi3 "run out of swap" experiment after > > updating source, kernel and world to r335576. Roughly the same things happen: > > Errors flood the console, when swap usage goes a bit over 80% the machine becomes > > unresponsive. No sign of the OOM assassin. > > > > However, -j4 buildworld got all the way to building libraries. With r334939 it > > always stopped in cross tools. That seems like a significant improvement > > in swap usage efficiency. Is this to be expected? > > > > >From the log file: > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/buildworld.log > > is the text: > > --- buildworld --- > make[1]: "/usr/src/Makefile.inc1" line 299: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. > make[1]: "/usr/src/Makefile.inc1" line 304: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. > > So the cross compiler and cross linker were not built: the existing > llvm files were used. > Ahh, so it wasn't a massive performance increase.... too bad! > > > What details were captured can be seen at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/ > > in case they're of interest. > > > You are still using the drive that gets the errors ( /dev/da0 ), > even if it is not being used for swapping. > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/console > > shows: > > _vfs_done():da0d[WRITE(offset=51819347968, length=131072)]error = 5 > g_vfs_done():da0d[WRITE(offset=51819479040, length=28672)]error = 5 > g_vfs_done():da0d[READ(offset=59586936832, length=32768)]error = 5 > g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) Yes, I'm still using that same device. The errors attributed to /dev/da0 were reported nearly two hours after the system first reported distress. That makes it hard to believe the errors caused the problem. It's easier to see in a re-run of the same experiment, with the last two lines of /var/log/messages tacked on to the gstat and swapinfo log. The file can be found in http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/2ndtest/ along with a pair of files sorted by read and write delay and a copy-paste of the top window after the power was cycled. The errors quoted above seem to start around timestamp Jun 25 19:54:28, but the system is clearly in trouble at timestamp Jun 25 17:58:55. OOMA never takes visible action which seems strange given the explicit getswapspace failures. Following timestamp Mon Jun 25 19:52:33 the log file becomes somewhat garbled. In looking through the log files of successful buildworlds there seem to be a random sprinkling of huge (~20 second) read and write delays, often clearing themselves in one or two 10-second sampling intervals. While they're certainly not good they weren't fatal. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 26 05:44:09 2018 Return-Path: Delivered-To: freebsd-arm@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 60CC410112EF for ; Tue, 26 Jun 2018 05:44:09 +0000 (UTC) (envelope-from pcrilly@goodgas.com.au) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 E11CF809F2 for ; Tue, 26 Jun 2018 05:44:08 +0000 (UTC) (envelope-from pcrilly@goodgas.com.au) Received: by mail-pf0-x233.google.com with SMTP id c22-v6so7576269pfi.2 for ; Mon, 25 Jun 2018 22:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=goodgas-com-au.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Lfnan1Dz1SerYRrx3PqZ2iTkd0Qtkz65wKE4D3urOGM=; b=ScvzI9PCcewlJXDPoDfxxuqLWTkLk0pCEblVw6IR0WJiIfoT6GZn1BRz3vZuIUmGb+ 8AI6XBs/RHq5cWDstqz5w9PXKXVVn5wXUrB3prpYVqMgud/HBOhJ3k9GY6GO6MxpPvLn XGheJ9ld5q84ttFNz8O6qG6GAsG+b3K5kEJ0I4O+FdwAeSzRsh937isqkbaDfTpx4j32 bZCP19ZNttHGNXhGiErnp1dm+naW0DGeT1wJgvtEM9htHTMpAHUVooqrHDoMBmQJavj5 k7/5R+MF4dmksHjHPOdPKU+teshFoyH1LDVnynR5gqSRFGjINoneQKFgMfi3J11phd4M ZOFg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Lfnan1Dz1SerYRrx3PqZ2iTkd0Qtkz65wKE4D3urOGM=; b=Q17QBXgWnTJsbEHLX93go3Q/cSzhPZDiWXAsE9FoLhxK831cqv3iHH+Rc3UjNcBeHJ em2Q98cdLyYxfeHn0Wt4OB6IDjT7rT6VyjAUt5XasE8TJYtGfOG/W04uSGz8xsVRmlKU 3GODzMnFc3YqdxL7/MoP2s+P/x+RQRdXZjPFInN1TNkvoawk7/HWHLGTkoxNwgw9EGyd KaVD6lNn0SKSEteh8trokX4mYLw7VE/4LSM2bxUXoTAl/n7qtHilMboa+ilFIzCieWET kUk+HQV/35F1m53wpJFxFTbpPp3Y21iemEpcpqvQXaA7BmLdHZNyu4ahQY5ezs/IGAfp 42Bg== X-Gm-Message-State: APt69E3aUo2vz/QuPRpJ07uDlW4V/dS17bZoKKfi5wKmuOiEfaDY9OT9 0ALy4kH2PDiG5GSPxoQqO9Nejvgm X-Google-Smtp-Source: ADUXVKJejCjdaBCUAx0ILmGLQm+WOK3Is2AR2brUd3RpruNKKGPrNu3yLjM+p9w1yjRGfrQlZjD2cg== X-Received: by 2002:a63:7a43:: with SMTP id j3-v6mr66861pgn.363.1529991846997; Mon, 25 Jun 2018 22:44:06 -0700 (PDT) Received: from [192.168.0.103] ([120.29.52.133]) by smtp.googlemail.com with ESMTPSA id p6-v6sm1738654pfd.176.2018.06.25.22.44.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 22:44:06 -0700 (PDT) Subject: Re: Status of FreeBSD CAM/MMC/SDIO? To: Ilya Bakulin Cc: freebsd-arm@freebsd.org References: <31736b31-bc31-67d2-aa41-431c79b8d538@goodgas.com.au> <20180625151210.GA38661@zugspitze.bakulin.de> From: Patrick Crilly Message-ID: <5e5fde8f-98c9-57b9-5fff-810e650c69d1@goodgas.com.au> Date: Tue, 26 Jun 2018 15:44:02 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180625151210.GA38661@zugspitze.bakulin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 05:44:09 -0000 On 26-Jun-18 1:12 AM, Ilya Bakulin wrote: > On Sun, Jun 24, 2018 at 12:57:10PM +1000, Patrick Crilly wrote: >> I was wondering if anyone knew what the current state of CAM/MMC/SDIO >> driver for Raspberry Pi is? >> > Hi Patrick, > For trying out MMCCAM on Raspberry Pi 3 you need an additional diff: > https://reviews.freebsd.org/D14168 > This adds a completely new driver, SDHOST, that operates a simplified > SDHC controller and uses it to access SD/MMC slot on Rpi3. A full-fledged SDHC > controller is then connected to the SDIO WiFi chip. Then you can use both SDHC > card and SDIO WiFi. > As for WiFi module itself, there is no driver for it yet. The work on the driver > has not started, because the prerequisite change https://reviews.freebsd.org/D12467 > hasn't been merged yet. I'm unable to provide any ETAs on merging that one, because > it's a pretty big architectural change. Thanks Ilya. I will apply the diffs and see if I can the driver working. Cheers, Patrick. -- "With great power comes great electricity bill" From owner-freebsd-arm@freebsd.org Tue Jun 26 06:25:38 2018 Return-Path: Delivered-To: freebsd-arm@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 410D4101340A for ; Tue, 26 Jun 2018 06:25:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 BA7EF81D67 for ; Tue, 26 Jun 2018 06:25:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id e15-v6so14873660iog.1 for ; Mon, 25 Jun 2018 23:25:37 -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=EngMMXn/m+iq7P99duH/tA+xv3aaUnrM4A2ie3x7fe0=; b=jpi+wtfndSaA3eTCPyc1ZbDUoLnowTv80GZGiXyI2dzJvfHsYCEhIxp7X+zQPeqFgG Wk0kq5CxBzGSiAQcQki8fNYCntA//InI70ZIiYUQEu03Lzn+60V/r27+bMZuJfp2Za1S 6QZDunb7+TjEYoDXtQfFZP5u5Lm0jIzhz/5qVlYvuAx/hrmM1Bw7KJM+dsQ9p8nUc3rE mCtOEXj2yrEnxzIeH+7IIWH1PqNMM7ZVAvztRFcerSPHUIrLs87DKHJpSdE+1xacOEjv RUVu0RbujHJpoJVXKX8DwLFx8MI+UOuV0M7w/iTsMfvUl/BR5xnfkdHyglptOdk9pQLh qyLQ== 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=EngMMXn/m+iq7P99duH/tA+xv3aaUnrM4A2ie3x7fe0=; b=YtSlJEiqXhYEy89krPLpX7v0LD687Aid39aEsEsjo5anSw5DvB9id2IeagcVd0Z9Mz +Ia0/BBVrKug/aMzszEC7nz0U0zveuIKX994FwrABpEE4GyLeE7tbBCn7h0XD8okIJjQ I1OxnacJdaM6yqx5cl5GYVR2JJFW9M2VgV8LfShaLz1lavIzha66od4kEdGj20bsaFFl +jEB9VI9oLKG21jnouGx5FAXyCQ7t/C1L9ucDjeVlC+ohHOLlQOqR7VAzO9Lpugra+cz q2gcuT5Q/l3rVDy0Kcd/SE5e1RinUIAiE/b0KOzV9QyYX+CFIo+RdU2CqRdgXdNuCKjS gI9A== X-Gm-Message-State: APt69E1gw6HUtxIoL2VWP6ubwNv1OT5OadGxIYSXmDXTYxq4W5ESZxjR FtHaJ96qi2fsZ3aL6CkR0ng5DwLhpBj/2MHnfWtWbw== X-Google-Smtp-Source: AAOMgpckFCf1k7Oazq/2yLnK1qQvOIugXNsQYH1voTpjPf0VwUhetKx8aFeDfdTuwmKjFL33WGu00o/fy7uSR1rS4PY= X-Received: by 2002:a6b:29c4:: with SMTP id p187-v6mr133088iop.299.1529994336956; Mon, 25 Jun 2018 23:25:36 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 23:25:36 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180626052451.GA17293@www.zefox.net> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> From: Warner Losh Date: Tue, 26 Jun 2018 00:25:36 -0600 X-Google-Sender-Auth: PhE_NW9NpiEELZ_OIS4yYM0T1ZE Message-ID: Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices To: bob prohaska Cc: Mark Millard , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 06:25:38 -0000 On Mon, Jun 25, 2018 at 11:24 PM, bob prohaska wrote: > On Sun, Jun 24, 2018 at 09:22:38PM -0700, Mark Millard wrote: > > On 2018-Jun-24, at 4:10 PM, bob prohaska wrote: > > > > > > > I've tried to replicate the RPi3 "run out of swap" experiment after > > > updating source, kernel and world to r335576. Roughly the same things > happen: > > > Errors flood the console, when swap usage goes a bit over 80% the > machine becomes > > > unresponsive. No sign of the OOM assassin. > > > > > > However, -j4 buildworld got all the way to building libraries. With > r334939 it > > > always stopped in cross tools. That seems like a significant > improvement > > > in swap usage efficiency. Is this to be expected? > > > > > > > >From the log file: > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/ > 1gbsdflash/buildworld.log > > > > is the text: > > > > --- buildworld --- > > make[1]: "/usr/src/Makefile.inc1" line 299: SYSTEM_COMPILER: Determined > that CC=cc matches the source tree. Not bootstrapping a cross-compiler. > > make[1]: "/usr/src/Makefile.inc1" line 304: SYSTEM_LINKER: Determined > that LD=ld matches the source tree. Not bootstrapping a cross-linker. > > > > So the cross compiler and cross linker were not built: the existing > > llvm files were used. > > > Ahh, so it wasn't a massive performance increase.... too bad! > > > > > What details were captured can be seen at > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/ > > > in case they're of interest. > > > > > > You are still using the drive that gets the errors ( /dev/da0 ), > > even if it is not being used for swapping. > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/console > > > > shows: > > > > _vfs_done():da0d[WRITE(offset=51819347968, length=131072)]error = 5 > > g_vfs_done():da0d[WRITE(offset=51819479040, length=28672)]error = 5 > > g_vfs_done():da0d[READ(offset=59586936832, length=32768)]error = 5 > > g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) > The device is broken if you get this. Period. I don't know if it is hardware, or software, but it is not a reliable storage device. Until that's fixed, you'll continue to have a terrible experience with it. > Yes, I'm still using that same device. The errors attributed to /dev/da0 > were reported nearly two hours after the system first reported distress. > That makes it hard to believe the errors caused the problem. > da0 is broken is what these errors mean. Broken. Not a little under the weather, or pining for the fjords, but an ex parrot. Errr, a broken thumb drive, a broken driver, or a drive that's missing a quirk. Trying to assign which partition is broken misses the bigger picture: you shouldn't see error rates like this. That means something is wrong. I presume the drive isn't defective (though that should be ruled out by swapping in a similar thumb drive), which leaves missing quirk (the umass driver is doing something to make it go catatonic which we may have quirks for since you can't probe it), umass has some kind of bug, or the usb bridge on the rpi goes out to lunch. Sorry to sound so harsh, but the data has been consistent on this for everything you've reported: it works for a while, then we get a bunch of errors then a reboot. We need to start narrowing down which of these three broad classes of root causes it is. I'd rank actual bad thumbdrive last on the list. It's a tossup for me between missing quirk and a bug in the rpi usb driver that manifests itself only under heavy load. IIRC, you said one of rpi2/3 works and the other doesn't, which would suggest a usb bridge driver problem... Warner Warner From owner-freebsd-arm@freebsd.org Tue Jun 26 07:01:15 2018 Return-Path: Delivered-To: freebsd-arm@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 33E8A101512C for ; Tue, 26 Jun 2018 07:01:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 978998306F for ; Tue, 26 Jun 2018 07:01:14 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5Q71RX3018088 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jun 2018 00:01:28 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5Q71QfJ018087; Tue, 26 Jun 2018 00:01:26 -0700 (PDT) (envelope-from fbsd) Date: Tue, 26 Jun 2018 00:01:26 -0700 From: bob prohaska To: Warner Losh Cc: Mark Millard , "freebsd-arm@freebsd.org" Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180626070126.GB17293@www.zefox.net> References: <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 07:01:15 -0000 On Tue, Jun 26, 2018 at 12:25:36AM -0600, Warner Losh wrote: > > > > > > _vfs_done():da0d[WRITE(offset=51819347968, length=131072)]error = 5 > > > g_vfs_done():da0d[WRITE(offset=51819479040, length=28672)]error = 5 > > > g_vfs_done():da0d[READ(offset=59586936832, length=32768)]error = 5 > > > g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) > > > > The device is broken if you get this. Period. I don't know if it is > hardware, or software, but it is not a reliable storage device. Until > that's fixed, you'll continue to have a terrible experience with it. > > > > da0 is broken is what these errors mean. Broken. Not a little under the > weather, or pining for the fjords, but an ex parrot. Errr, a broken thumb > drive, a broken driver, or a drive that's missing a quirk. Trying to assign > which partition is broken misses the bigger picture: you shouldn't see > error rates like this. That means something is wrong. I presume the drive > isn't defective (though that should be ruled out by swapping in a similar > thumb drive), which leaves missing quirk (the umass driver is doing > something to make it go catatonic which we may have quirks for since you > can't probe it), umass has some kind of bug, or the usb bridge on the rpi > goes out to lunch. > > Sorry to sound so harsh, but the data has been consistent on this for > everything you've reported: it works for a while, then we get a bunch of > errors then a reboot. We need to start narrowing down which of these three > broad classes of root causes it is. I'd rank actual bad thumbdrive last on > the list. It's a tossup for me between missing quirk and a bug in the rpi > usb driver that manifests itself only under heavy load. IIRC, you said one > of rpi2/3 works and the other doesn't, which would suggest a usb bridge > driver problem... > My references to rpi2 probably aren't meaningful; swap usage is about 10% of what happens on rpi3. All I can do is swap media. I think the easiest thing to try is dd the old da0 onto a second thumb drive. a second experiment is to set up a new boot microSD and thumb drive (same brand, model and size, slightly newer); basically setting up a new system. Which approach is apt to be more informative? Here's the dmesg output for the device and its potential successor: da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number 4C530001211014123270 da0: 40.000MB/s transfers da0: 59840MB (122552320 512 byte sectors) da0: quirks=0x2 da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: Removable Direct Access SPC-4 SCSI device da1: Serial Number AA010428162242131598 da1: 40.000MB/s transfers da1: 59836MB (122544516 512 byte sectors) da1: quirks=0x2 Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 26 09:07:38 2018 Return-Path: Delivered-To: freebsd-arm@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 E0614101D26B for ; Tue, 26 Jun 2018 09:07:38 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from ppp150-101-221-139.static.internode.on.net (2001-44b8-4170-0a00-0000-0000-0000-0002.static.ipv6.internode.on.net [IPv6:2001:44b8:4170:a00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "150.101.221.139", Issuer "Bunya Technology Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0855D88726; Tue, 26 Jun 2018 09:07:37 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) X-Clacks-Overhead: GNU Terry Pratchett Received: from DHCP.tawonga.bunyatech.com.au (DHCP.tawonga.bunyatech.com.au [10.0.1.78] (may be forged)) (authenticated bits=0) by cope.tawonga.bunyatech.com.au (8.15.2/8.15.2/MSA) with ESMTPSA id w5Q97UX6042431 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 26 Jun 2018 19:07:30 +1000 (AEST) (envelope-from bscott@bunyatech.com.au) Subject: Re: [CFT] Newer kgdb bits for testing To: freebsd-arm@FreeBSD.org References: From: Brian Scott Message-ID: <1fdb19a5-412a-5a40-ad9c-07f2f7b326fa@bunyatech.com.au> Date: Tue, 26 Jun 2018 19:07:30 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 09:07:39 -0000 Not an expert on kgdb but I've been having a bit of a fight with it this week on my Raspberry-Pi. I've just built this and tested it on my 'problem' vmcore file. Worked like a dream. It confirmed an answer that had taken a lot of work for me to dig out with the existing version. Thanks for the work. Brian P.S. CC'ing you directly because the mail lists seem to dislike my email for some reason (some of the time). Must get around to investigating when I've got time. On 26/6/18 9:41 am, John Baldwin wrote: > At BSDCan I finally sat down and wrote a FreeBSD/arm kernel target for the > ports kgdb (GDB 8.1). It passed simple testing "live" on my little RPi, > but I haven't tested it against a vmcore. (In theory cross-debugging a > vmcore should Just Work(tm)). I'd like to default FreeBSD/arm to storing > the old gdb in /usr/libexec for use by crashinfo, but the ports kgdb needs > a bit more testing before we can throw the switch. > > To build the new kgdb, you can either apply the patches from > https://reviews.freebsd.org/D16013 to the devel/gdb port and rebuild > the port, or you can build gdb from the 'freebsd-8.1-kgdb' branch > of github.com/bsdjhb/gdb.git. > > One thing in particular I haven't been able to test yet is unwinding > across an in-kernel trapframe (for an exception taken while in the > kernel for example). It wasn't clear to me from reading the assembly > bits in exception.S if I need to pull the PC and LR values from a > different offset in struct trapframe for in-kernel trapframes vs > traps from userland. > From owner-freebsd-arm@freebsd.org Tue Jun 26 10:40:15 2018 Return-Path: Delivered-To: freebsd-arm@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 6E86B102033E for ; Tue, 26 Jun 2018 10:40:15 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AE808B476 for ; Tue, 26 Jun 2018 10:40:14 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w5QAeCAa035184; Tue, 26 Jun 2018 11:40:12 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w5QAeBKq035183; Tue, 26 Jun 2018 11:40:11 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> Date: Tue, 26 Jun 2018 11:40:11 +0100 Organization: Dyslexic Fish To: imp@bsdimp.com, fbsd@www.zefox.net Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Tue, 26 Jun 2018 11:40:12 +0100 (BST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 10:40:15 -0000 Warner Losh wrote: > > > _vfs_done():da0d[WRITE(offset=51819347968, length=131072)]error = 5 > > > g_vfs_done():da0d[WRITE(offset=51819479040, length=28672)]error = 5 > > > g_vfs_done():da0d[READ(offset=59586936832, length=32768)]error = 5 > > > g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) > > > > The device is broken if you get this. Period. I don't know if it is > hardware, or software, but it is not a reliable storage device. Until > that's fixed, you'll continue to have a terrible experience with it. > [ ... ] > Sorry to sound so harsh, but the data has been consistent on this for > everything you've reported: it works for a while, then we get a bunch of > errors then a reboot. We need to start narrowing down which of these three > broad classes of root causes it is. I'd rank actual bad thumbdrive last on > the list. It's a tossup for me between missing quirk and a bug in the rpi > usb driver that manifests itself only under heavy load. IIRC, you said one > of rpi2/3 works and the other doesn't, which would suggest a usb bridge > driver problem... For what it's worth, I had the same errors on a rpi3 a few months ago, and eventualy gave up "to sort it tomorrow" - it hasn't been powered on since, but I still want to get it working. The system would run fine, but give the vfs errors on the 128GB usb thumb drive every week - like clockwork, when one of the heavier periodic jobs ran. I was running the latest CURRENT at the time. The thumb drive works fine elsewhere, and indeed - did on the same hardware when I test installed a linux install, and thrashed the hell out of it. I'll fire it up again - hopefully I'll still have the same results, and with 2 of us, we may find the cause quicker. (n.b. i never had swap errors, but I can't recall if i ever configured swap on the usb drive) Cheers, Jamie From owner-freebsd-arm@freebsd.org Tue Jun 26 14:38:07 2018 Return-Path: Delivered-To: freebsd-arm@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 10B451029484 for ; Tue, 26 Jun 2018 14:38:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-3.consmr.mail.bf2.yahoo.com (sonic301-3.consmr.mail.bf2.yahoo.com [74.6.129.42]) (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 9C8E973137 for ; Tue, 26 Jun 2018 14:38:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 2DMXJoEVM1k0wfwIM8T.PGA5sgnYJMsD0zN64VJ6UH0Boj.GpHZsSvjxRHBTR9u WWeKCO6qOor33H6u7_TWy18TludsvlY5pl3G_6NkiayEqoLfQUo_1M1LOzZvWUwSNYkziP1lfwA5 bq_Geb_OcS_Ju4zuUBjrFfTcalufPmGs7uZc7BwC57UghEXVA4xd8Hoxh4KBMNvf3rS6UI6XRF13 yj5F3omcLSDR2Nvm9LndNUn7kfUMvgWjJfb6ImiVNmbJbZ8LjAoqpGqeKsaanP9Su63DKm17f4zo 8FzEzmk5yKlNCKzUXUFihwfic..h9UWjkeR.lDZFlNtaHvn_Ixdj.6L36eTxsZP1b6V9LxPur7pf Vmiqq3l6iSHR_Rp.dkhoRdNhLxgOw_M0Ixi_AiG3HEuqdFZVctJR1hxHrpaYoY2fs591KhoFRPhp mG1fqwcfV0mkNA11ydxQVZLOekXwu9AyxJPb4UPnMdcXxwjFUL6rwVngvwUCQZ0zL2X.8_x5GYU6 bm3sfWtUAJWQmov6vAWyI6m_MANZflP_Q1WIBl7DSpsocUwvtcSyq8utMbVDK8lxidXDSRMKjApu AYG08YFAPEK4DeIEk8dwmr36EqPsBu87AXE03.EYv9ClR21eSfYd4.UL.l7MjpCKGeB3WvfbZadx .vWJTKFo6QF1C6_YKSX7ctGuNEy0Way6wwklfcPdZeYoNvheujB.1JerpQ9PjedNl5hma03Md4Vo _nnIARTULsp.7iylhz_znj.D68OKGaSwrQQfyDUv48pWMgnWmLkt9l83cP6HT2xnQUOHPLDPHMxg rDsf_UeIcmefsImy3N0gOjveK86vd14xnKIVd0Znrn7tbEP4KNolX5evsgfmQmqJXgz49.Ynh41J Ixml52KD4ZoKonwiaYDp8YU14Gm5YGLBBQyDmTiMHMTIjTfuNDEgvbrL_WakNqOWrTziSF_t6E4O nzauTXT4FEmu_OkPLJEgUuqFG3TVfdh5iyR47Xx70gA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Tue, 26 Jun 2018 14:38:05 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp428.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4b3c61cfdadcc6f5617b6c506c7de04a; Tue, 26 Jun 2018 14:38:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> Date: Tue, 26 Jun 2018 07:37:59 -0700 Cc: Warner Losh , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> To: Jamie Landeg-Jones , bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 14:38:07 -0000 On 2018-Jun-26, at 3:40 AM, Jamie Landeg-Jones = wrote: > Warner Losh wrote: >=20 >>>> _vfs_done():da0d[WRITE(offset=3D51819347968, length=3D131072)]error = =3D 5 >>>> g_vfs_done():da0d[WRITE(offset=3D51819479040, length=3D28672)]error = =3D 5 >>>> g_vfs_done():da0d[READ(offset=3D59586936832, length=3D32768)]error = =3D 5 >>>> g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) >>>=20 >>=20 >> The device is broken if you get this. Period. I don't know if it is >> hardware, or software, but it is not a reliable storage device. Until >> that's fixed, you'll continue to have a terrible experience with it. >>=20 >=20 > [ ... ] >=20 >> Sorry to sound so harsh, but the data has been consistent on this for >> everything you've reported: it works for a while, then we get a bunch = of >> errors then a reboot. We need to start narrowing down which of these = three >> broad classes of root causes it is. I'd rank actual bad thumbdrive = last on >> the list. It's a tossup for me between missing quirk and a bug in the = rpi >> usb driver that manifests itself only under heavy load. IIRC, you = said one >> of rpi2/3 works and the other doesn't, which would suggest a usb = bridge >> driver problem... >=20 > For what it's worth, I had the same errors on a rpi3 a few months ago, = and > eventualy gave up "to sort it tomorrow" - it hasn't been powered on = since, but > I still want to get it working. >=20 > The system would run fine, but give the vfs errors on the 128GB usb = thumb > drive every week - like clockwork, when one of the heavier periodic = jobs ran. >=20 > I was running the latest CURRENT at the time. The thumb drive works = fine elsewhere, > and indeed - did on the same hardware when I test installed a linux = install, > and thrashed the hell out of it. >=20 > I'll fire it up again - hopefully I'll still have the same results, = and with 2 > of us, we may find the cause quicker. >=20 > (n.b. i never had swap errors, but I can't recall if i ever configured = swap on the usb > drive) The presence of the errors is a confounding variable for the other issues being looked into. It would likely be better for the effort to be split: A) Looking into the drive errors and what range of contexts get them, hoping to find something to fix the issue (such as by adding a quirk). B) Looking into the swapping and Out Of Memory process killing --but absent such errors being involved. (For now this might require a different instance of the same type of device or a different type of device.) It seems too complicated to be investigating (B) but in a context with the drive errors also involved. As I remember, Bob P. Did reproduce drive errors even without the problem drive being used for swapping. This too suggests (A) as separate activity. If only one of the 2 is targeted first, (A) may be the better one to pursue for those with reproducible examples. For those with contexts that lack the drive errors, (B) activity might show a contrasting behavior for lack of drive errors --or the behavior might be reproduced. Cross checking on if drive errors started showing up would be appropriate. An intersting question for (A) might be if some drive benchmark program(s) might reproduce the drive errors. If such was found, the context for reproduction would be far simpler than buildworld buildkernel use. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jun 26 14:43:11 2018 Return-Path: Delivered-To: freebsd-arm@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 5858C1029995 for ; Tue, 26 Jun 2018 14:43:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8D5673730 for ; Tue, 26 Jun 2018 14:43:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5QEhIfp019573 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jun 2018 07:43:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5QEhICZ019572; Tue, 26 Jun 2018 07:43:18 -0700 (PDT) (envelope-from fbsd) Date: Tue, 26 Jun 2018 07:43:18 -0700 From: bob prohaska To: Jamie Landeg-Jones Cc: imp@bsdimp.com, freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180626144318.GC17293@www.zefox.net> References: <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 14:43:11 -0000 On Tue, Jun 26, 2018 at 11:40:11AM +0100, Jamie Landeg-Jones wrote: > Warner Losh wrote: > > > > > _vfs_done():da0d[WRITE(offset=51819347968, length=131072)]error = 5 > > > > g_vfs_done():da0d[WRITE(offset=51819479040, length=28672)]error = 5 > > > > g_vfs_done():da0d[READ(offset=59586936832, length=32768)]error = 5 > > > > g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) > > > > > > > The device is broken if you get this. Period. I don't know if it is > > hardware, or software, but it is not a reliable storage device. Until > > that's fixed, you'll continue to have a terrible experience with it. > > > > [ ... ] > > > Sorry to sound so harsh, but the data has been consistent on this for > > everything you've reported: it works for a while, then we get a bunch of > > errors then a reboot. We need to start narrowing down which of these three > > broad classes of root causes it is. I'd rank actual bad thumbdrive last on > > the list. It's a tossup for me between missing quirk and a bug in the rpi > > usb driver that manifests itself only under heavy load. IIRC, you said one > > of rpi2/3 works and the other doesn't, which would suggest a usb bridge > > driver problem... > > For what it's worth, I had the same errors on a rpi3 a few months ago, and > eventualy gave up "to sort it tomorrow" - it hasn't been powered on since, but > I still want to get it working. > It might be worth quite a lot 8-) > The system would run fine, but give the vfs errors on the 128GB usb thumb > drive every week - like clockwork, when one of the heavier periodic jobs ran. > That is something I've not seen. > I was running the latest CURRENT at the time. The thumb drive works fine elsewhere, > and indeed - did on the same hardware when I test installed a linux install, > and thrashed the hell out of it. > > I'll fire it up again - hopefully I'll still have the same results, and with 2 > of us, we may find the cause quicker. > > (n.b. i never had swap errors, but I can't recall if i ever configured swap on the usb > drive) > To be clear, the USB thumb drive in question wasn't supporting a swap partition at the time of the error message quoted above. /da0d held /usr. Swap was on the boot microSD card and was deliberately too small (1 GB) to let -j4 buildworld run to completion. All attempts to use swap on the suspected USB flash drive resulted in OOMA kills, all attempts to use sufficient swap (2 GB or more) not on the suspected USB flash drive resulted in successful -j4 buildworlds. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 26 15:18:33 2018 Return-Path: Delivered-To: freebsd-arm@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 3E615102ACE2 for ; Tue, 26 Jun 2018 15:18:33 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 973F074D35 for ; Tue, 26 Jun 2018 15:18:32 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5QFIhvJ019667 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jun 2018 08:18:44 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5QFIhM3019666; Tue, 26 Jun 2018 08:18:43 -0700 (PDT) (envelope-from fbsd) Date: Tue, 26 Jun 2018 08:18:43 -0700 From: bob prohaska To: Mark Millard Cc: Jamie Landeg-Jones , Warner Losh , freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180626151843.GD17293@www.zefox.net> References: <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 15:18:33 -0000 On Tue, Jun 26, 2018 at 07:37:59AM -0700, Mark Millard wrote: > > > On 2018-Jun-26, at 3:40 AM, Jamie Landeg-Jones wrote: > > > Warner Losh wrote: > > > >>>> _vfs_done():da0d[WRITE(offset=51819347968, length=131072)]error = 5 > >>>> g_vfs_done():da0d[WRITE(offset=51819479040, length=28672)]error = 5 > >>>> g_vfs_done():da0d[READ(offset=59586936832, length=32768)]error = 5 > >>>> g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) > >>> > >> > >> The device is broken if you get this. Period. I don't know if it is > >> hardware, or software, but it is not a reliable storage device. Until > >> that's fixed, you'll continue to have a terrible experience with it. > >> > > > > [ ... ] > > > >> Sorry to sound so harsh, but the data has been consistent on this for > >> everything you've reported: it works for a while, then we get a bunch of > >> errors then a reboot. We need to start narrowing down which of these three > >> broad classes of root causes it is. I'd rank actual bad thumbdrive last on > >> the list. It's a tossup for me between missing quirk and a bug in the rpi > >> usb driver that manifests itself only under heavy load. IIRC, you said one > >> of rpi2/3 works and the other doesn't, which would suggest a usb bridge > >> driver problem... > > > > For what it's worth, I had the same errors on a rpi3 a few months ago, and > > eventualy gave up "to sort it tomorrow" - it hasn't been powered on since, but > > I still want to get it working. > > > > The system would run fine, but give the vfs errors on the 128GB usb thumb > > drive every week - like clockwork, when one of the heavier periodic jobs ran. > > > > I was running the latest CURRENT at the time. The thumb drive works fine elsewhere, > > and indeed - did on the same hardware when I test installed a linux install, > > and thrashed the hell out of it. > > > > I'll fire it up again - hopefully I'll still have the same results, and with 2 > > of us, we may find the cause quicker. > > > > (n.b. i never had swap errors, but I can't recall if i ever configured swap on the usb > > drive) > > The presence of the errors is a confounding variable for the other > issues being looked into. > > It would likely be better for the effort to be split: > > A) Looking into the drive errors and what range of contexts > get them, hoping to find something to fix the issue (such > as by adding a quirk). > > B) Looking into the swapping and Out Of Memory process killing > --but absent such errors being involved. (For now this might > require a different instance of the same type of device > or a different type of device.) > > It seems too complicated to be investigating (B) but in a > context with the drive errors also involved. > > As I remember, Bob P. Did reproduce drive errors even without > the problem drive being used for swapping. This too suggests > (A) as separate activity. > Indeed, it is a requirement. If the suspect device is used for swapping OOMA kills prevent the test from progressing to the point of failure. > If only one of the 2 is targeted first, (A) may be the > better one to pursue for those with reproducible examples. > > For those with contexts that lack the drive errors, (B) > activity might show a contrasting behavior for lack of drive > errors --or the behavior might be reproduced. Cross checking > on if drive errors started showing up would be appropriate. > > An intersting question for (A) might be if some drive benchmark > program(s) might reproduce the drive errors. If such was found, > the context for reproduction would be far simpler than buildworld > buildkernel use. > The machine exhibiting the errors has Peter Holm's stress2 test suite installed. It compiled and ran, but apparently some art is required to craft a test case that exercises the weak points of interest without tripping over weak points not of interest. I'd be pleased to try it, but will need some guidance. If there are more expedient things to attempt please indicate what they are. For example would it be informative to simply try a -j3 or -j2 buildworld? In the past -j1 buildworld has run to completion but hasn't been tried recently. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 26 20:16:03 2018 Return-Path: Delivered-To: freebsd-arm@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 F23C11017BE8 for ; Tue, 26 Jun 2018 20:16:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (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 963DB8280B for ; Tue, 26 Jun 2018 20:16:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: N6kLx94VM1mblcHqk3UIktA3EhIuY5Q6OsPsRZvUCXDdLneSfY.ErSZ.L96X.u5 o.Rs2npUT3CboEI3vsxq_Z_8INvVuLsa_pGfS1uesmMMcubrISxiMnHSMMhdv9EETK2uF8nHG1Bl aL084eZ2aEsGl131dcNsxHPpca78SPJphVhKF7glYC_wBIyCidkfnvyg6jVGOVgugIRM.yyxgIME EnPtcHU_dX2YeiNckhbdAiYRbarlna7G9O_GOzN2mhAFcnC9y5EgWnbh4vYPIOo1lymlbqPWfqGR e5qGN3jEq9gPzDWDQC87qXZWgEQedH89fBC773ZGWTBzeSKb3OWk7uPs5pBzEOgkyUhk30WZc0V_ LmpR6j_90iUmgWDstBmsNnqpbLmQV4U378BQsoX1Blg911YStGYvL0fHs2VHZ1ytvhyQhlUFFzlG it53RMKb1qv8zzVmWeQwTMpOjfqHp3W43fEJvZFvC..h5o8RF4fCF3ZH.ZCsQnuAHctC1sdVUlfm MV7jeYr2XEoI7FGVs40gws4uRpW9kbppatXd4Wv7g3CHgajrG6rVe5MvORIAejC9ZEwRKOv8sLfN zUtK1tBcxwx7SxPPFf_xFkNAg7ANXqH4mLJ83jz4VfLfJe5B.NTsW5Vzc6ndx2JWE_Z.ygADNQrP r5Oq7DogYgQfrlSW7xMJIyg7yrBfS2O7APLrSoJwrrbjKqV2mTvRrHj3GTjQj1_9zGrCSPgiEt6d uSFfrcp3SJ7rHtMFEybRToxVeDqMS3So27Pu0nCRAL.qvTWD.pzPmGAjOhsNptrJaljqpXiR9cST qeC54dlFOQkGqkS7a49LJO9uQAY8EbE.a6wYs3jJApEOQDWbHdQ6RGazAqETMfrXizScgy2HexGE 04CG0JhDc2cU7FC1BzxWouXV.YiJeIlArcd7N8LYMAe_wWD34Opp2JzOI2x5hFbcFuCir72ZhPhF i1Hg0rSRv0UD5QrngODBTkUsP5I70jgZw8NAr_wMKocT.Hi78WnlKPMe8SDQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 26 Jun 2018 20:16:01 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 23ddd967cca5a54e2b1a0226534d8608; Tue, 26 Jun 2018 20:15:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180626151843.GD17293@www.zefox.net> Date: Tue, 26 Jun 2018 13:15:54 -0700 Cc: Jamie Landeg-Jones , Warner Losh , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> References: <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 20:16:03 -0000 On 2018-Jun-26, at 8:18 AM, bob prohaska wrote: > On Tue, Jun 26, 2018 at 07:37:59AM -0700, Mark Millard wrote: >> >> >> . . . >> >> As I remember, Bob P. Did reproduce drive errors even without >> the problem drive being used for swapping. This too suggests >> (A) as separate activity. >> > Indeed, it is a requirement. If the suspect device is used for swapping > OOMA kills prevent the test from progressing to the point of failure. > Looking back at http://www.zefox.net/~fbsd/rpi3/swaptests/ and information about /dev/da0 rive errors it does not appear that a combination with: A) sufficient swap (> 1.5 GiByte total?) but no use of swap on any partition on /dev/da0 and: B) use of /dev/da0 for /usr/ and /var/ and: C) Records from the console showing errors (or notes indicating lack of such errors). exists. So I was remembering incorrectly. I'm not claiming such a combination is the best direction for the next tests, but absent such tests there is no compare/contrast to know if /dev/da0 would still get errors despite the system having sufficient swap present on other drives. Thus, I would not go so far as "is a requirement" on the evidence available. We do have evidence for the system having insufficient swap space: this context seems to have the current status "is sufficient but might not be necessary" for /dev/da0 getting drive errors. As for simpler contexts, one that would swap but would be far simpler a context than buildworld buildkernel might be something like using the stress port via options like: stress -d 2 -m 3 --vm-keep (The option values likely could need adjustment from context to context to match available resources. The above is not carefully tailored to your context or a modern context. It dates back to 2016-Jan-22 for showing vnode based swap failures in a 1 GiByte RAM + 1 GiByte swap-file context [inside virtualbox on amd64 hardware]: see comment 3 of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 .) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jun 26 22:28:26 2018 Return-Path: Delivered-To: freebsd-arm@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 C6B80101E77F for ; Tue, 26 Jun 2018 22:28:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4107787186 for ; Tue, 26 Jun 2018 22:28:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5QMSZ5Z021847 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jun 2018 15:28:36 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5QMSZka021846; Tue, 26 Jun 2018 15:28:35 -0700 (PDT) (envelope-from fbsd) Date: Tue, 26 Jun 2018 15:28:34 -0700 From: bob prohaska To: Mark Millard Cc: Jamie Landeg-Jones , Warner Losh , freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180626222834.GA20270@www.zefox.net> References: <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 22:28:26 -0000 On Tue, Jun 26, 2018 at 01:15:54PM -0700, Mark Millard wrote: > On 2018-Jun-26, at 8:18 AM, bob prohaska wrote: > > > On Tue, Jun 26, 2018 at 07:37:59AM -0700, Mark Millard wrote: > >> > >> > >> . . . > >> > >> As I remember, Bob P. Did reproduce drive errors even without > >> the problem drive being used for swapping. This too suggests > >> (A) as separate activity. > >> > > Indeed, it is a requirement. If the suspect device is used for swapping > > OOMA kills prevent the test from progressing to the point of failure. > > > > Looking back at http://www.zefox.net/~fbsd/rpi3/swaptests/ > and information about /dev/da0 rive errors it does not > appear that a combination with: > > A) sufficient swap (> 1.5 GiByte total?) but no use of swap on > any partition on /dev/da0 > and: > B) use of /dev/da0 for /usr/ and /var/ > and: > C) Records from the console showing errors (or notes > indicating lack of such errors). > > exists. So I was remembering incorrectly. > > I'm not claiming such a combination is the best direction for > the next tests, but absent such tests there is no > compare/contrast to know if /dev/da0 would still get errors > despite the system having sufficient swap present on other > drives. Thus, I would not go so far as "is a requirement" on > the evidence available. > I just didn't bother to record successful runs. I'm logging one now. > We do have evidence for the system having insufficient swap > space: this context seems to have the current status "is > sufficient but might not be necessary" for /dev/da0 > getting drive errors. > Not sure I understand here. Basically there seem to be three cases: Enough swap not on da0, -j4 buildworld completes. Any swap on da0, -j4 buildworld is killed by OOMA Not enough swap not on da0, -j4 buildworld crashes the machine eventually. Are there other combinations I've overlooked? The first two don't seem worth repeating, at least not often. > > As for simpler contexts, one that would swap but would be > far simpler a context than buildworld buildkernel might be > something like using the stress port via options like: > > stress -d 2 -m 3 --vm-keep > > (The option values likely could need adjustment from context > to context to match available resources. The above is not > carefully tailored to your context or a modern context. > It dates back to 2016-Jan-22 for showing vnode based swap > failures in a 1 GiByte RAM + 1 GiByte swap-file context > [inside virtualbox on amd64 hardware]: see comment 3 of > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 .) > > This is new to me and entirely separate from Peter Holm's stress2. It compiled without a hitch and seems worth a try. Thank you! bob prohaska From owner-freebsd-arm@freebsd.org Wed Jun 27 02:09:22 2018 Return-Path: Delivered-To: freebsd-arm@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 5C5361027E67 for ; Wed, 27 Jun 2018 02:09:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.ne1.yahoo.com (sonic311-23.consmr.mail.ne1.yahoo.com [66.163.188.204]) (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 C92C78E1D8 for ; Wed, 27 Jun 2018 02:09:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: dmQxc18VM1kH4nOajh72mAQ5mhr15yHIrL4t0J5pZA09_.NdrL0kl7MKBa21v6S pR.4eDwwCHzpm2mz3oC_lYQ7dJwqWx69cU2vDffuGaJPdjMKg4FHoBIiLu0ubGAwrqVaW9MSwKQn HdNkgZGYiwGvfgBJV3XubcjtuhlZl3P0iaiCRAkTkqYJfbpPd8AplpRc43f68L5k_Xb5boNg6im3 YU9JYpufvTjBPCOdxOul5sQC7KarUHKlaAdBzkIu3BRbLKWHBtGEZJvxoo0yhw7Obuw5FEwtoJsJ x4k4iJ6Zx5gBgWj8xUUfV6rsUqHL_o4BSkOZTvUtRLcIiRYLDab7I0sbM1mERHfE5K4UDdJV9DWF rb9.N9ztrbtmFRv7csOy.dboL.XxHAwVgPHadzMxDqfcvdHPpJSwLFfBAdiVSJkppTtUAM4XO2V6 YeNAQEuC7WE0vbmzKnCuek7jPGGpb2GBrAlU6e_CKIyzoOSsQhes0cfdkSLKkKSIouLVM.NWHXOt rr2nTXhDvoxsnxOZS2FK5Fsi1bojTbokqYXRibdSlqpPuR5iCqJoCnOYBeOqzMnBMkLmLm_uku2H 1w.W9b7Foo6uH5P0qqcvW4wiCIRBCgrr7j46zymTw.DlVNUOp2jjgLMNXOKeLoCOuVQ4lSFDYaF9 q0Kn8uI_mNJClj8FoiAvykM.J1HXYvtkmjHbH67OUneauykzImSWZXRO7c8jaScKs2g5ExoTulld INuDOk4KoXJJTMIdad8Ti8iozLu.m.JG2nSM02Eji4.fpOeBzENzi1qtk7kpyzfvCifsA6460vfi 7W6sa8OmAcVvM2D21ZEVoQiPRtihBmt3cbi5tvyzXzUEBwQdvcPCi6mFhvR6QYPnRiTH8elfjr2F .H.Lbl2s.whZL8MA.dsOcooMEWFi37P85PzczCkN4kMoKsPDiVvCVezko1J2bkaojPjTQziHwGEC fDp12ZVTt6RSzGX.jBYfpoi9wOedOMdrx5A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Wed, 27 Jun 2018 02:09:15 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp401.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0696509309fab90cd916918bf738bac6; Wed, 27 Jun 2018 02:09:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180626222834.GA20270@www.zefox.net> Date: Tue, 26 Jun 2018 19:09:09 -0700 Cc: Jamie Landeg-Jones , Warner Losh , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> References: <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 02:09:22 -0000 On 2018-Jun-26, at 3:28 PM, bob prohaska wrote: > On Tue, Jun 26, 2018 at 01:15:54PM -0700, Mark Millard wrote: >> On 2018-Jun-26, at 8:18 AM, bob prohaska wrote: >> >>> On Tue, Jun 26, 2018 at 07:37:59AM -0700, Mark Millard wrote: >>>> >>>> >>>> . . . >>>> >>>> As I remember, Bob P. Did reproduce drive errors even without >>>> the problem drive being used for swapping. This too suggests >>>> (A) as separate activity. >>>> >>> Indeed, it is a requirement. If the suspect device is used for swapping >>> OOMA kills prevent the test from progressing to the point of failure. >>> >> >> Looking back at http://www.zefox.net/~fbsd/rpi3/swaptests/ >> and information about /dev/da0 rive errors it does not >> appear that a combination with: >> >> A) sufficient swap (> 1.5 GiByte total?) but no use of swap on >> any partition on /dev/da0 >> and: >> B) use of /dev/da0 for /usr/ and /var/ >> and: >> C) Records from the console showing errors (or notes >> indicating lack of such errors). >> >> exists. So I was remembering incorrectly. >> >> I'm not claiming such a combination is the best direction for >> the next tests, but absent such tests there is no >> compare/contrast to know if /dev/da0 would still get errors >> despite the system having sufficient swap present on other >> drives. Thus, I would not go so far as "is a requirement" on >> the evidence available. >> > > I just didn't bother to record successful runs. I'm logging one now. > >> We do have evidence for the system having insufficient swap >> space: this context seems to have the current status "is >> sufficient but might not be necessary" for /dev/da0 >> getting drive errors. >> > Not sure I understand here. Basically there seem to be three cases: > Enough swap not on da0, -j4 buildworld completes. > Any swap on da0, -j4 buildworld is killed by OOMA > Not enough swap not on da0, -j4 buildworld crashes the machine eventually. > > Are there other combinations I've overlooked? The first two don't seem > worth repeating, at least not often. "buildworld completes with /dev/da0 errors" vs. "buildworld completes without /dev/da0 errors" (for: enough swap not on /dev/da0 with no swap on /dev/da0 ). That is a little simplistic, as there can be multiple retries before FreeBSD gives up. Normal is no retries needed. Going from rare single retries to frequent multiple retries but no giving-up to it giving up sometimes is all abnormal as I understand. But there are degrees of abnormal. And, yes, I have had past examples of significant drive reports during buildworld that let buildworld appear to complete. (Not that I trusted the result or the drive involved after such, at least as the drive was powered/connected at the time.) For "any swap on da0" and "not enough swap not on da0" (with no swap on da0) I'd add to your descriptions: "with /dev/da0 errors" (again simplistic). This goes along with my suggestion to split the /dev/da0 error investigation from the investigations of OMMA behavior and crashing-the-machine: avoiding any confounding. (For now I do not have access to a context for doing rpi3 examples myself.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jun 27 05:40:35 2018 Return-Path: Delivered-To: freebsd-arm@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 1804C1001CF5 for ; Wed, 27 Jun 2018 05:40:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 132569545C for ; Wed, 27 Jun 2018 05:40:32 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5R5eTFr023080 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jun 2018 22:40:31 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5R5eSWR023079; Tue, 26 Jun 2018 22:40:28 -0700 (PDT) (envelope-from fbsd) Date: Tue, 26 Jun 2018 22:40:27 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180627054027.GA22144@www.zefox.net> References: <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 05:40:35 -0000 On Tue, Jun 26, 2018 at 07:09:09PM -0700, Mark Millard wrote: > > > On 2018-Jun-26, at 3:28 PM, bob prohaska wrote: > > > On Tue, Jun 26, 2018 at 01:15:54PM -0700, Mark Millard wrote: > >> On 2018-Jun-26, at 8:18 AM, bob prohaska wrote: > >> > >>> On Tue, Jun 26, 2018 at 07:37:59AM -0700, Mark Millard wrote: > >>>> > >>>> > >>>> . . . > >>>> > >>>> As I remember, Bob P. Did reproduce drive errors even without > >>>> the problem drive being used for swapping. This too suggests > >>>> (A) as separate activity. > >>>> > >>> Indeed, it is a requirement. If the suspect device is used for swapping > >>> OOMA kills prevent the test from progressing to the point of failure. > >>> > >> > >> Looking back at http://www.zefox.net/~fbsd/rpi3/swaptests/ > >> and information about /dev/da0 rive errors it does not > >> appear that a combination with: > >> > >> A) sufficient swap (> 1.5 GiByte total?) but no use of swap on > >> any partition on /dev/da0 > >> and: > >> B) use of /dev/da0 for /usr/ and /var/ > >> and: > >> C) Records from the console showing errors (or notes > >> indicating lack of such errors). > >> > >> exists. So I was remembering incorrectly. > >> > >> I'm not claiming such a combination is the best direction for > >> the next tests, but absent such tests there is no > >> compare/contrast to know if /dev/da0 would still get errors > >> despite the system having sufficient swap present on other > >> drives. Thus, I would not go so far as "is a requirement" on > >> the evidence available. > >> > > > > I just didn't bother to record successful runs. I'm logging one now. > > > >> We do have evidence for the system having insufficient swap > >> space: this context seems to have the current status "is > >> sufficient but might not be necessary" for /dev/da0 > >> getting drive errors. > >> > > Not sure I understand here. Basically there seem to be three cases: > > Enough swap not on da0, -j4 buildworld completes. > > Any swap on da0, -j4 buildworld is killed by OOMA > > Not enough swap not on da0, -j4 buildworld crashes the machine eventually. ^^^^^^^^^^ OK, here's my error. The third case should have been "not enough swap on mmcsd0". > > > > Are there other combinations I've overlooked? The first two don't seem > > worth repeating, at least not often. > > "buildworld completes with /dev/da0 errors" vs. "buildworld completes > without /dev/da0 errors" (for: enough swap not on /dev/da0 with no > swap on /dev/da0 ). > > That is a little simplistic, as there can be multiple retries > before FreeBSD gives up. Normal is no retries needed. Going > from rare single retries to frequent multiple retries but no > giving-up to it giving up sometimes is all abnormal as I > understand. But there are degrees of abnormal. > > And, yes, I have had past examples of significant drive reports > during buildworld that let buildworld appear to complete. (Not > that I trusted the result or the drive involved after such, at > least as the drive was powered/connected at the time.) > > For "any swap on da0" and "not enough swap not on da0" (with > no swap on da0) I'd add to your descriptions: "with /dev/da0 > errors" (again simplistic). The only case where I've seen crashes and /dev/da0 errors is with insufficient swap on mmcsd0. I've come to ignore OOMA kills as too familiar to be interesting. > > This goes along with my suggestion to split the /dev/da0 > error investigation from the investigations of OMMA behavior > and crashing-the-machine: avoiding any confounding. > >From what I've seen, OOMA isn't associated with da0 errors and crashes. To see the latter, OOMA must be avoided. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Jun 27 06:30:58 2018 Return-Path: Delivered-To: freebsd-arm@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 958A51004069 for ; Wed, 27 Jun 2018 06:30:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-13.consmr.mail.bf2.yahoo.com (sonic310-13.consmr.mail.bf2.yahoo.com [74.6.135.123]) (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 364A796AC4 for ; Wed, 27 Jun 2018 06:30:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: m3tMVNkVM1lwBSRGx0Rz_NWYvuLDN7bSRiTJi9I3XFroLdgxOiu_gmFEn0.mq22 fj9_OM.b6l9Gf.bBMrBxvuD.CNpbUwSnOtxag8iCVHeQqoIrIMFu3G9q_zqI.Gq3zIvbSAOQF5PU 81riY9pgkO2JR4gS.AJM.mmNWYVbTUcCmo.VvoQ5u7IdCiNeYo1TNEoEKuivdiAZuojlwKNCZdXi j7wLFIWvWuxDqRSsRI1Zrozoo4cLsvFFDEnGYlt0Gts.I.01XMZ6myvSdIXLBbIrvoy5zCsH9Y27 90lsh_w0LvGte29wdglxXeAqtU9h1RjLHklTLU7kpBduFKDRcXQHqThOhSRZB4cPlFO43NkWO3JT RmdaaI9mwuFesV.GPnWMwXv3AVBeBuD6WKSySSd0FCVy443LkP.apA1Sdn2zka1xPvsfv9uxccw5 L0cs43_S3IkKiHjWnO9fyyj4eNs2Q6JpeaWqodZIgQ3mjmojXodxa5rmsliFYILgPeuKL8S9Mr.H 0evgAKH_G4.hGETMap7Y.lfpGrN1ac97YX9DZYiK3J7jq2gWgfOmrJrlLcWQpaoHzjNhrfVMcArt aS39LEoT2SQtzCWkgwoPGx27RAxsXWCN3PEg0t_0mlYMz5u6BzrxlieCDdR.bT7g8b1J5y4cJKb9 yr5ckMdbKj8TG6G31XLJ5F4fjwjWapLpKS0sjTAqgsXOCdRtWUXOG5XOGlK0t_8nCFUau1LNnq5x jKzWfn_US9HCafMV2swkIbCRaGQ91xmNJW_5Z18xGxaHhWTfXy._atdxdlZr_PFTbumiHby2owdR lLxg18VjJAx1seCD9GUDshoyO3VqDHfsUnNgi23lXaaHYjRr7hePsE7iExcJ3yMSRMSh59BBoaVN tN4HV3J0RtZ6gcPHa_.jVwtdj88ziLH0metqN3FxQoapWzy0VNq8ghrjG5vJo8ypoJ0xNA4MH36G gGty3jH.w3cF4a2sn5gtn8cMsjWIJnsEm Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 27 Jun 2018 06:30:57 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp404.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c7840db5a7f361770c5fa542451b8bba; Wed, 27 Jun 2018 06:30:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180627054027.GA22144@www.zefox.net> Date: Tue, 26 Jun 2018 23:30:52 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 06:30:58 -0000 On 2018-Jun-26, at 10:40 PM, bob prohaska wrote: > On Tue, Jun 26, 2018 at 07:09:09PM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2018-Jun-26, at 3:28 PM, bob prohaska = wrote: >>=20 >>> On Tue, Jun 26, 2018 at 01:15:54PM -0700, Mark Millard wrote: >>>> On 2018-Jun-26, at 8:18 AM, bob prohaska = wrote: >>>>=20 >>>>> On Tue, Jun 26, 2018 at 07:37:59AM -0700, Mark Millard wrote: >>>>>>=20 >>>>>>=20 >>>>>> . . . >>>>>>=20 >>>>>> As I remember, Bob P. Did reproduce drive errors even without >>>>>> the problem drive being used for swapping. This too suggests >>>>>> (A) as separate activity. >>>>>>=20 >>>>> Indeed, it is a requirement. If the suspect device is used for = swapping >>>>> OOMA kills prevent the test from progressing to the point of = failure. >>>>>=20 >>>>=20 >>>> Looking back at http://www.zefox.net/~fbsd/rpi3/swaptests/ >>>> and information about /dev/da0 rive errors it does not >>>> appear that a combination with: >>>>=20 >>>> A) sufficient swap (> 1.5 GiByte total?) but no use of swap on >>>> any partition on /dev/da0 >>>> and: >>>> B) use of /dev/da0 for /usr/ and /var/ >>>> and: >>>> C) Records from the console showing errors (or notes >>>> indicating lack of such errors). >>>>=20 >>>> exists. So I was remembering incorrectly. >>>>=20 >>>> I'm not claiming such a combination is the best direction for >>>> the next tests, but absent such tests there is no >>>> compare/contrast to know if /dev/da0 would still get errors >>>> despite the system having sufficient swap present on other >>>> drives. Thus, I would not go so far as "is a requirement" on >>>> the evidence available. >>>>=20 >>>=20 >>> I just didn't bother to record successful runs. I'm logging one now. >>>=20 >>>> We do have evidence for the system having insufficient swap >>>> space: this context seems to have the current status "is >>>> sufficient but might not be necessary" for /dev/da0 >>>> getting drive errors. >>>>=20 >>> Not sure I understand here. Basically there seem to be three cases: >>> Enough swap not on da0, -j4 buildworld completes. >>> Any swap on da0, -j4 buildworld is killed by OOMA >>> Not enough swap not on da0, -j4 buildworld crashes the machine = eventually. > ^^^^^^^^^^ > OK, here's my error. The third case should have been > "not enough swap on mmcsd0".=20 >=20 >=20 >>>=20 >>> Are there other combinations I've overlooked? The first two don't = seem=20 >>> worth repeating, at least not often. >>=20 >> "buildworld completes with /dev/da0 errors" vs. "buildworld completes >> without /dev/da0 errors" (for: enough swap not on /dev/da0 with no >> swap on /dev/da0 ). >>=20 >> That is a little simplistic, as there can be multiple retries >> before FreeBSD gives up. Normal is no retries needed. Going >> from rare single retries to frequent multiple retries but no >> giving-up to it giving up sometimes is all abnormal as I >> understand. But there are degrees of abnormal. >>=20 >> And, yes, I have had past examples of significant drive reports >> during buildworld that let buildworld appear to complete. (Not >> that I trusted the result or the drive involved after such, at >> least as the drive was powered/connected at the time.) >>=20 >> For "any swap on da0" and "not enough swap not on da0" (with >> no swap on da0) I'd add to your descriptions: "with /dev/da0 >> errors" (again simplistic). >=20 > The only case where I've seen crashes and /dev/da0 errors is with > insufficient swap on mmcsd0. I've come to ignore OOMA kills as=20 > too familiar to be interesting.=20 "crashes and /dev/da0 errors": A) Any examples of /dev/da0 errors without crashes? B) Any examples of crashes without /dev/da0 errors? C) All examples that do either also does the other (so both always go together)? (I've having trouble parsing a specific meaning for the reference. I did not go back trough all the logs again to identify the combinations recorded.) For (A), have you tried any examples of: sufficient swap on mmcsd0 (or other such) with no swap on da0 (but /usr and /var on /dev/da0)? If yes, did you check on if there were /dev/da0 errors logged? What, if any, /dev/da0 errors where logged? None? For (B), have you tried any examples of: insufficient swap on (say) mmcsd0 and no use of the /dev/da0 drive that has reported errors at all, /usr/ and /var not on mmcsd0 (or whatever was used for swap) either? Did some drive end up reporting errors? Which? Did the system still crash as well? Have such test-context combinations been tried? Without any logs to look at for such alternatives, I can not try to compare/contrast such to the others examples. >>=20 >> This goes along with my suggestion to split the /dev/da0 >> error investigation from the investigations of OMMA behavior >> and crashing-the-machine: avoiding any confounding. >>=20 > =46rom what I've seen, OOMA isn't associated with da0 errors and = crashes. > To see the latter, OOMA must be avoided. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jun 27 19:42:05 2018 Return-Path: Delivered-To: freebsd-arm@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 DD01C1004914 for ; Wed, 27 Jun 2018 19:42:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D5B68F935 for ; Wed, 27 Jun 2018 19:42:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5RJgINq028292 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Jun 2018 12:42:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5RJgH2h028291; Wed, 27 Jun 2018 12:42:17 -0700 (PDT) (envelope-from fbsd) Date: Wed, 27 Jun 2018 12:42:17 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180627194217.GA27793@www.zefox.net> References: <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 19:42:05 -0000 On Tue, Jun 26, 2018 at 11:30:52PM -0700, Mark Millard wrote: > On 2018-Jun-26, at 10:40 PM, bob prohaska wrote: > [apologies to all, especially Mark, for the length of this tale. Keeping it short, sweet and accurate is harder than expected!] [big snip] > > A) Any examples of /dev/da0 errors without crashes? No. /dev/da0 errors always end in a panic or hang. > B) Any examples of crashes without /dev/da0 errors? No. > C) All examples that do either also does the other > (so both always go together)? Yes. Rarely, on hands-off reboot, da0 errors were reported, with eventual panic, but fsck always cleared the problem. Later on it seemed booting first to single user, then exiting to multiuser fixed (or avoided) the problem. So, ephemeral /dev/da0 errors have been seen without running -j4 buildworld. Next time it happens I'll try to capture the messages. IIRC, they started with "lost mount". Once the system goes multi-user no da0 errors have been seen apart from those during -j4 buildworld. > > (I've having trouble parsing a specific meaning for > the reference. I did not go back trough all the logs > again to identify the combinations recorded.) > > For (A), have you tried any examples of: > > sufficient swap on mmcsd0 (or other such) with no swap > on da0 (but /usr and /var on /dev/da0)? Yes, that is the configuration which completes successfully. > > If yes, did you check on if there were /dev/da0 errors > logged? What, if any, /dev/da0 errors where logged? > None? Correct, no errors on da0 when -j4 buildworld is successful. > For (B), have you tried any examples of: > > insufficient swap on (say) mmcsd0 and no use of the > /dev/da0 drive that has reported errors at all, > /usr/ and /var not on mmcsd0 (or whatever was used > for swap) either? Did some drive end up reporting > errors? Which? Did the system still crash as well? > I think this is the standard test case: /usr and /var on /dev/da0 /tmp on /dev/mmcsd0s3a swap on /dev/mmcsd0s3b This configuration has crashed reliably with errors on /dev/da0 but no other "disk" errors. Did I understand the question correctly? > > > Have such test-context combinations been tried? > > Without any logs to look at for such alternatives, I > can not try to compare/contrast such to the others > examples. > Understood. The matrix of test conditions is not completely filled, and the test of different media for /dev/da0 has not yet been made. I'd like to play with stress2 and ports/sysutils/stress before doing that. There is a new, successful -j4 buildworld swapuse.log for the case of 3 GB of USB flash swap at http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/3gbusbflash/ The system is now up to r335655 and I'm trying to replicate earlier crash behavior before proceeding further. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Jun 28 01:13:05 2018 Return-Path: Delivered-To: freebsd-arm@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 AF2D210238F8 for ; Thu, 28 Jun 2018 01:13:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 35DC47D683 for ; Thu, 28 Jun 2018 01:13:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: jzF8jRMVM1n2wevQhO1QvO0dmm0hQAWANek94icqFaNNThRTpRiX9RpW7Cl1w_O E1_w.RuQBfIoIoejovoKXRP_SMQFB7Y.Q2ypzsTI8.y4ux69PlFmmFIzhQLe9gl_cYUmLsxOLWHV 4aflU79Bnzwlwd0wlVSqyyoy1MQrX7TFyS0csJMWnChhlBuFTh571GIsKxw3L8Ve4TcJpZn1A13q nJfZtKD4KonLmbin7KlbdsFl0u99Hkzn6gSufXUSSzJDEhQ9QY5tkgA_m9Gs_94kqKFuSZDuJF2S xDg4ath7XJtEny5L1j7BfFXTKVEatpnexG7qxwAXL4ctnFFahnOVfz56pP_JgM8RdK6.hrDZ53sd _MFaRWNokCkfaSfFW0e2lM9Loqx..r9kR.hBEYrK4B6O_li2KPzeLNfKGcy2L9ys.e20x_CC1EBO 2J7bnd.tHs3BItS0bOLPHz4ji4tnr4B1yn3Uew9bSl1DgStWKWH29Hb4_ejAKX2taOLF1BqemH6q QiaK8KscTdgZvsDVD2fDw5cFj_fSlSI_1p0eqSluivneCXNJX3dD19Ec_jWQ1TIh1TT_.8ggOoUg YKkS7ZYRjCMMweXskFTzcbzjDtr2hL9eGCVXaFYnRsutka7_SDe9wDW2USv4xM2_M4WPz1hp.tSx iMrMWHTfHLVWNAyFNeaQxGxHzUlIQIh4.YVFobiVM5ybaMRwED0CnQx4UX9CLhydzSciM9f4zQV9 FfoqIjtrzxwxWHhT2fQ1eqAJdwoghdKbqa3Igf02bnmvyFkULJ6ZOXaqynqbAZqUiVfJNAFdQ4cR IP4GbJMQN9OvfXr0suCTh4Lof2m_CgtrWOfXGvK91HOuVWJLlNFWILAqx0cLCqbZEXvJ2fyCI5qy RfLHjcXwXNYeCKaUrZuUBX9hpYpUSqGYlpngHM3lGO.j8Q.tjT9tY.8KaiwZ9jP7.vsHsNQxDji. fVR76WVcd995pGlm.0pVuwNUJGY8jng-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Jun 2018 01:12:58 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp410.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fab8e5df08b823c7af1db1845fced47e; Thu, 28 Jun 2018 01:12:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180627194217.GA27793@www.zefox.net> Date: Wed, 27 Jun 2018 18:12:53 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 01:13:05 -0000 On 2018-Jun-27, at 12:42 PM, bob prohaska wrote: > On Tue, Jun 26, 2018 at 11:30:52PM -0700, Mark Millard wrote: >> On 2018-Jun-26, at 10:40 PM, bob prohaska = wrote: >>=20 >> . . . >> For (A), have you tried any examples of: >>=20 >> sufficient swap on mmcsd0 (or other such) with no swap >> on da0 (but /usr and /var on /dev/da0)? > Yes, that is the configuration which completes successfully. >>=20 >> If yes, did you check on if there were /dev/da0 errors >> logged? What, if any, /dev/da0 errors where logged? >> None? > Correct, no errors on da0 when -j4 buildworld is successful. Good to know. Thanks. >> For (B), have you tried any examples of: >>=20 >> insufficient swap on (say) mmcsd0 and no use of the >> /dev/da0 drive that has reported errors at all, >> /usr/ and /var not on mmcsd0 (or whatever was used >> for swap) either? Did some drive end up reporting >> errors? Which? Did the system still crash as well? >>=20 > I think this is the standard test case: > /usr and /var on /dev/da0 > /tmp on /dev/mmcsd0s3a > swap on /dev/mmcsd0s3b >=20 > This configuration has crashed reliably with errors on /dev/da0 but no = other "disk" errors. > Did I understand the question correctly? I intended for "no use of /dev/da0" to indicate that not even /usr or /var were from the device that has been logging the errors. For example: having /usr or /var on the mechanical disk and the known-problem disk not connected at all. This would get either no-errors or some other device would get errors, possibly the mechanical disk (if that was the type used for a test). >>=20 >>=20 >> Have such test-context combinations been tried? >>=20 >> Without any logs to look at for such alternatives, I >> can not try to compare/contrast such to the others >> examples. >>=20 >=20 > Understood. The matrix of test conditions is not completely filled, > and the test of different media for /dev/da0 has not yet been made. > I'd like to play with stress2 and ports/sysutils/stress before doing > that. It would be handy for something simpler than buildworld to be able to induce some of the types of problems, for sure. > There is a new, successful -j4 buildworld swapuse.log for the case > of 3 GB of USB flash swap at >=20 > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/3gbusbflash/ >=20 I do not see a console.log or notes about the console messages (or lack of such). Where there any messages there of note? No device errors? Was such checked for? > The system is now up to r335655 and I'm trying to replicate=20 > earlier crash behavior before proceeding further.=20 >=20 Sounds good. I will note that the following might help memory handling for your context (small memory context): Author: alc Date: Tue Jun 26 18:29:56 2018 New Revision: 335674 URL: https://svnweb.freebsd.org/changeset/base/335674 Log: Update the physical page selection strategy used by vm_page_import() = so that it does not cause rapid fragmentation of the free physical = memory. =20 Reviewed by: jeff, markj (an earlier version) Differential Revision: https://reviews.freebsd.org/D15976 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jun 28 02:24:44 2018 Return-Path: Delivered-To: freebsd-arm@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 A96CE102B3A7 for ; Thu, 28 Jun 2018 02:24:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 29BEC81900 for ; Thu, 28 Jun 2018 02:24:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5S2OwZt030415 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Jun 2018 19:24:58 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5S2Ovt3030414; Wed, 27 Jun 2018 19:24:57 -0700 (PDT) (envelope-from fbsd) Date: Wed, 27 Jun 2018 19:24:57 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180628022457.GA30110@www.zefox.net> References: <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 02:24:44 -0000 On Wed, Jun 27, 2018 at 06:12:53PM -0700, Mark Millard wrote: > On 2018-Jun-27, at 12:42 PM, bob prohaska wrote: > > > On Tue, Jun 26, 2018 at 11:30:52PM -0700, Mark Millard wrote: > >> On 2018-Jun-26, at 10:40 PM, bob prohaska wrote: > >> > >> . . . > >> For (A), have you tried any examples of: > >> > >> sufficient swap on mmcsd0 (or other such) with no swap > >> on da0 (but /usr and /var on /dev/da0)? > > Yes, that is the configuration which completes successfully. > >> > >> If yes, did you check on if there were /dev/da0 errors > >> logged? What, if any, /dev/da0 errors where logged? > >> None? > > Correct, no errors on da0 when -j4 buildworld is successful. > > Good to know. Thanks. > > >> For (B), have you tried any examples of: > >> > >> insufficient swap on (say) mmcsd0 and no use of the > >> /dev/da0 drive that has reported errors at all, > >> /usr/ and /var not on mmcsd0 (or whatever was used > >> for swap) either? Did some drive end up reporting > >> errors? Which? Did the system still crash as well? > >> > > I think this is the standard test case: > > /usr and /var on /dev/da0 > > /tmp on /dev/mmcsd0s3a > > swap on /dev/mmcsd0s3b > > > > This configuration has crashed reliably with errors on /dev/da0 but no other "disk" errors. > > Did I understand the question correctly? > > I intended for "no use of /dev/da0" to indicate > that not even /usr or /var were from the device > that has been logging the errors. For example: > having /usr or /var on the mechanical disk and > the known-problem disk not connected at all. > Not yet, but absent new developments I'm running out of other things to try. My hesitations stems partly from my own sloth, but mostly from a concern that I'll introduce confounding changes unintentionally. I'm hopeful Jaimie will get his Pi3 running and see something interesting. Some time ago I asked whether it would be better to dd the existing da0 onto another device or better to construct a complete new installation (new snapshot on a new microSD plus a new USB thumb drive). Would you venture a guess? > This would get either no-errors or some other > device would get errors, possibly the mechanical > disk (if that was the type used for a test). > > >> > >> > >> Have such test-context combinations been tried? > >> > >> Without any logs to look at for such alternatives, I > >> can not try to compare/contrast such to the others > >> examples. > >> > > > > Understood. The matrix of test conditions is not completely filled, > > and the test of different media for /dev/da0 has not yet been made. > > I'd like to play with stress2 and ports/sysutils/stress before doing > > that. > > It would be handy for something simpler than buildworld to be > able to induce some of the types of problems, for sure. > It's difficult to gather persuasive test statistics at one trial per day 8-) > > There is a new, successful -j4 buildworld swapuse.log for the case > > of 3 GB of USB flash swap at > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/3gbusbflash/ > > > > I do not see a console.log or notes about the console messages > (or lack of such). Where there any messages there of note? No > device errors? Was such checked for? > Nothing on the console apart from normal remote-login failures. The gstat data shows widely-scattered large delays, but they're brief and don't seem to cause trouble. > > The system is now up to r335655 and I'm trying to replicate > > earlier crash behavior before proceeding further. > > > > Sounds good. > > I will note that the following might help memory handling > for your context (small memory context): > > Author: alc > Date: Tue Jun 26 18:29:56 2018 > New Revision: 335674 > URL: https://svnweb.freebsd.org/changeset/base/335674 > > Log: > Update the physical page selection strategy used by vm_page_import() so > that it does not cause rapid fragmentation of the free physical memory. > > Reviewed by: jeff, markj (an earlier version) > Differential Revision: https://reviews.freebsd.org/D15976 > It's encouraging that folks are making some progress. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Jun 28 03:08:09 2018 Return-Path: Delivered-To: freebsd-arm@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 919D9102FF9E for ; Thu, 28 Jun 2018 03:08:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 16AA384123 for ; Thu, 28 Jun 2018 03:08:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: D_T6fRgVM1nH.E91HmZIeNQ33X67CYIgtr57JUfUJ2kKCDxWHyT5vaoEboV62CY REgfI.MdrZlqHSw0pfRz.ZG9BO4iGjB_y0pYh3LPR5XuucvkTprguWTp9fylh6q7BVdIaj7D1JM1 FFvwNHPrYsL0C5pwQ7hikxldFEAgd7GInTYkkLiOpog3SbXcP1qIL.JTHiEL8vEfiKozuPcFG2dq 9jM0RNSa2Ti.egIVuqSciUij_WiMBhVZKok.2C3JuVTVeUxFgiAeF66OpLTJOh3g01wvHdrwWhCk NG2gwNDzB2bqk6wvqW_YX_AxcV7mJBUfpF_WAni.jTlpKhrhsv1rDekLALVkqWvYGylC5wGU9k0T op86ENz_Q3JXFxKvLJzYQDJFbq3HQLBdkR2IuZB2wjQ9OjSFe1lCsEFVBsxvTzgWz8lDddbpEVEp weH2IyKXWjwjZFYtYUErJACN_ByBg6zRsAO9godNNPrpfO7qmmXLppuVI8wajS2THxkbbEyC9QH7 fpv2blsqAMrEHuSokCTm6yBRp8HnMK88sSs4.SEQ4rOyoKuA0lGHJCEvnds3eQc9pukZE5YoSFlH EYA0HCWG_lAv2glQfTL9ph_w_bhoo35NH9VsdmFWwEVZmxyjaX7z9k5uDtcVvzl4uZG339yC8vls Vpufo7ct_lS_bxrYPQfOF9PXn1ezFMNkfI1Tb_I.0WyyuxpeT.Q1P69Sk3HfP6Xy3ZaovVLyYmTJ QnCXsCde2sBaGkve7zKCIDAWqbSZDKepnxuDH06gJ5u_OsnV3gWajSIek84KJ6s22G6gcG8w_J4t AcQr4t8e2WTdAGRUzFjeP5T2BOd2Ol6Em5b6KGmne_XqVSjOPcKksN0htHSvPpLRYmb4O3GQLUOZ w1u3ngpggL1v0lEKDwJf5_YJxvYsJjLoQ9G8Ptv879AD541OVZgRMHztjAlYugvEb4AesFjzlHq6 idRYQcM8SjK1QQLc5C.UltepWhSgC Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Jun 2018 03:08:07 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp409.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4ed461f45197dd995d84f5e28745961b; Thu, 28 Jun 2018 03:08:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180628022457.GA30110@www.zefox.net> Date: Wed, 27 Jun 2018 20:08:01 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> References: <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 03:08:09 -0000 On 2018-Jun-27, at 7:24 PM, bob prohaska wrote: > On Wed, Jun 27, 2018 at 06:12:53PM -0700, Mark Millard wrote: >> On 2018-Jun-27, at 12:42 PM, bob prohaska = wrote: >>=20 >>> On Tue, Jun 26, 2018 at 11:30:52PM -0700, Mark Millard wrote: >>>> . . . >>=20 >>>> For (B), have you tried any examples of: >>>>=20 >>>> insufficient swap on (say) mmcsd0 and no use of the >>>> /dev/da0 drive that has reported errors at all, >>>> /usr/ and /var not on mmcsd0 (or whatever was used >>>> for swap) either? Did some drive end up reporting >>>> errors? Which? Did the system still crash as well? >>>>=20 >>> I think this is the standard test case: >>> /usr and /var on /dev/da0 >>> /tmp on /dev/mmcsd0s3a >>> swap on /dev/mmcsd0s3b >>>=20 >>> This configuration has crashed reliably with errors on /dev/da0 but = no other "disk" errors. >>> Did I understand the question correctly? >>=20 >> I intended for "no use of /dev/da0" to indicate >> that not even /usr or /var were from the device >> that has been logging the errors. For example: >> having /usr or /var on the mechanical disk and >> the known-problem disk not connected at all. >>=20 > Not yet, but absent new developments I'm running out of > other things to try. My hesitations stems partly from my > own sloth, but mostly from a concern that I'll introduce > confounding changes unintentionally. I'm hopeful Jaimie > will get his Pi3 running and see something interesting. >=20 > Some time ago I asked whether it would be better to > dd the existing da0 onto another device or better to > construct a complete new installation (new snapshot > on a new microSD plus a new USB thumb drive). Would > you venture a guess? /dev/da0 is logging write errors. fsck does not correct individual blocks that are part of the content of a file. /dev/da0 is also logging read errors, and, again, fsck does not correct individual blocks that are part of the content of a file. (fsck works on the file system that describes information for finding/using files and their content. [simplistic description]) So I would not trust a copy of /dev/da0 to have avoided the copying already-existing (as read) corruptions of the intended content in various places. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jun 28 07:10:19 2018 Return-Path: Delivered-To: freebsd-arm@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 2EC8E10214B2 for ; Thu, 28 Jun 2018 07:10:19 +0000 (UTC) (envelope-from 01000164453a7ba2-17d57160-e027-4e65-9aa7-412bd86721d3-000000@amazonses.com) Received: from a9-75.smtp-out.amazonses.com (a9-75.smtp-out.amazonses.com [54.240.9.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD17F8E109 for ; Thu, 28 Jun 2018 07:10:18 +0000 (UTC) (envelope-from 01000164453a7ba2-17d57160-e027-4e65-9aa7-412bd86721d3-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=rnokqi3lgnnhpavmjvg22v2o5suhcadc; d=countryrealestate.co.za; t=1530169818; h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type:List-Unsubscribe:List-Id; bh=rFDD9h0cbAGl9ukP5QpLngAYHc/7wjJErEedp25qjjE=; b=e93tW7lt9pVHnz1zDzcZo/XToCBmmNNSBWrbKmIj4OD69u2pRbAN+9YvqX3QuwL2 Ipla8reBecrTN3TOwsn5TvOmmNPmgVpRoIOS2gJj4QO5LXARe1oY8mC/AusmTOnpHbE rawEkSQIQCBG08fevZY6W8TX8AhZSwsfHOpPTOMo= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1530169818; h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type:List-Unsubscribe:List-Id:Feedback-ID; bh=rFDD9h0cbAGl9ukP5QpLngAYHc/7wjJErEedp25qjjE=; b=gEYl5xLMAR6/YznkXXZzlfH1xSnE7q1oeRBbDH3XcKLmuyoBz0DI9sJZyeZCUrhS ATEEioD9Mai1HNXn4oYw0eNqS1gpKwp3W7969RUaws/c3bN2sNuRfXiwW9ztAbRY8Zr SMs9rEy5orASvfyq+XzT47B4hIeTb4sQ2VlLr+VQ= Message-ID: <01000164453a7ba2-17d57160-e027-4e65-9aa7-412bd86721d3-000000@email.amazonses.com> Date: Thu, 28 Jun 2018 07:10:18 +0000 Subject: Luxury Apartments | 74 Available in this Country Estate From: Paradiso | Somerset West Reply-To: Paradiso | Somerset West To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 X-Xxno-Tracking-Did: 0 X-Xxno-Subscriber-Uid: cx164rn2ze855 X-Xxno-Mailer: SwiftMailer - 5.4.x X-Xxno-EBS: http://yourclick.co.za/index.php/lists/block-address X-Xxno-Delivery-Sid: 33 X-Xxno-Customer-Uid: ck943am3f1f2e X-Xxno-Customer-Gid: 2 X-Xxno-Campaign-Uid: ww812qolhkaea X-Sender: estate@countryrealestate.co.za X-Report-Abuse: Please report abuse for this campaign here: http://yourclick.co.za/index.php/campaigns/ww812qolhkaea/report-abuse/jj752s6g7oab4/cx164rn2ze855 X-Receiver: freebsd-arm@freebsd.org Precedence: bulk Feedback-ID: 1.us-east-1.H++pt9akrtMeI9O2Xvhkd27fB1TMSDH6wLssS1ueKvY=:AmazonSES X-SES-Outgoing: 2018.06.28-54.240.9.75 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 07:10:19 -0000 =20 =09=09SITARI COUNTRY ESTATE PRESENTS PARADISO PREMIUM APARTME= NTS NOW SELLING FROM R 1 725 000 SOMERSET WEST =E2=80=A2 CAPE TOWN = =09=09=C2=A0 =09=09=C2=A0 =09=09VISIT OUR WEBSITE http= ://yourclick.co.za/index.php/campaigns/ww812qolhkaea/track-url/cx164rn2ze85= 5/8e4d173eecf8c89a7c3eafebf3cc1141fc0db5bb =09=09VIEW PROPERTY OFFERINGS= http://yourclick.co.za/index.php/campaigns/ww812qolhkaea/track-url/cx164= rn2ze855/460988cdf468009e09bced25c2ee8ce3e6e9c35a =09=09GET MORE INFO = http://yourclick.co.za/index.php/campaigns/ww812qolhkaea/track-url/cx164rn2= ze855/75dbbd6d96394577af9319e8fa059d8bc1f97f33 =09=09=C2=A0 =09= =09=C2=A0 LIMITED AVAILABILITY 74 OPPORTUNITIES AVAILABLE=20 = =09=09=C2=A0 =09=09=C2=A0 =09=09ENQUIRE NOW http://yourclick.co.= za/index.php/campaigns/ww812qolhkaea/track-url/cx164rn2ze855/75dbbd6d963945= 77af9319e8fa059d8bc1f97f33 =09=09=C2=A0 =09=09=C2=A0 =09=09= =C2=A0 PARADISO PREMIUM APARTMENTS 1-, 2 & 3-BEDROOMS AND 1 & 2-BA= THROOMS=20 =09=09=C2=A0 PREMIUM FINISHES INCLUDE: =E2=80=A2 St= ack-away doors that allow for seamless indoor to outdoor living =E2=80= =A2 Exquisitely designed with top imported brands, including Smeg applia= nces & Grohe sanitary ware =E2=80=A2 Exposed trusses =E2=80=A2 Enginee= red stone countertops =E2=80=A2 Stack-away doors that allow for seamless = indoor to outdoor living =E2=80=A2 Ground-floor units with tranquil priv= ate gardens =E2=80=A2 Built-in braai=20 =09=09=C2=A0 =09=09= =C2=A0 =09=09GET MORE INFO http://yourclick.co.za/index.php/campaigns/= ww812qolhkaea/track-url/cx164rn2ze855/d54deababb6a2f93a2a99a74e6b21039a656a= 5c8 =09=09=C2=A0 =09=09ENQUIRE NOW http://yourclick.co.za/index.php= /campaigns/ww812qolhkaea/track-url/cx164rn2ze855/75dbbd6d96394577af9319e8fa= 059d8bc1f97f33 =09=09=C2=A0 =09=09=C2=A0 =09=09=C2=A0 = =09=09EMAIL US =09=09CALL US http://yourclick.co.za/index.php/campaign= s/ww812qolhkaea/track-url/cx164rn2ze855/3a542052178cefb97ef66f7dbf65dac1c3e= f6fd5 =09=09VISIT WEBSITE http://yourclick.co.za/index.php/campaigns/w= w812qolhkaea/track-url/cx164rn2ze855/8e4d173eecf8c89a7c3eafebf3cc1141fc0db5= bb =09=09Click here if you're not able to view this mailer http://y= ourclick.co.za/index.php/campaigns/ww812qolhkaea/track-url/cx164rn2ze855/56= 11d745e46650e8aecdb7ef20a532136447addb =09=09click here to unsubscrib= e http://yourclick.co.za/index.php/campaigns/ww812qolhkaea/track-url/cx16= 4rn2ze855/c6aaf4a4459b67f3676ecc872b43d10ad9cef944 or _report abuse htt= p://yourclick.co.za/index.php/campaigns/ww812qolhkaea/track-url/cx164rn2ze8= 55/df5cc5704f9ce1b4ab37ba1496c594a6aacbef7f_ =20 From owner-freebsd-arm@freebsd.org Thu Jun 28 16:33:22 2018 Return-Path: Delivered-To: freebsd-arm@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 62426101F0C1 for ; Thu, 28 Jun 2018 16:33:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB16483660 for ; Thu, 28 Jun 2018 16:33:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5SGXTVA033483 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jun 2018 09:33:30 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5SGXTbR033482; Thu, 28 Jun 2018 09:33:29 -0700 (PDT) (envelope-from fbsd) Date: Thu, 28 Jun 2018 09:33:29 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180628163328.GA33408@www.zefox.net> References: <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 16:33:22 -0000 It turns out that Peter Holm's stress2 suite will trigger a crash whose console messages look superficially like those produced by -j4 buildworld. The storage configuration is the same: /var and /usr on USB flash, 1 GB swap on microSD. The gstat/swapinfo log file is at http://www.zefox.net/~fbsd/rpi3/swaptests/r335655/1gbsdflash/stress2/swapuse.log An early sign of trouble is dT: 10.042s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 16 57 0 0 0.0 57 6351 237.6 0 0 0.0 100.2 mmcsd0 15 57 0 0 0.0 57 6351 237.6 0 0 0.0 100.2 mmcsd0s3 14 57 0 0 0.0 57 6351 237.7 0 0 0.0 100.2 mmcsd0s3a Thu Jun 28 00:52:49 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 32320 1016256 3% Jun 28 00:52:05 www bob[2122]: Starting test df.cfg Jun 28 00:52:45 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3467, size: 4096 dT: 10.004s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 19 51 0 0 0.0 51 5796 239.5 0 0 0.0 100.2 mmcsd0 17 51 0 0 0.0 51 5796 239.5 0 0 0.0 100.2 mmcsd0s3 17 51 0 0 0.0 51 5796 239.6 0 0 0.0 100.2 mmcsd0s3a Thu Jun 28 00:52:59 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 32320 1016256 3% Jun 28 00:52:05 www bob[2122]: Starting test df.cfg Jun 28 00:52:45 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3467, size: 4096 Here's the spot where the /dev/da0 errors begin in the gstat/swapinfo log: dT: 10.002s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 4 9 1 3 131.4 9 186 46.9 0 0 0.0 28.5 mmcsd0 1 1 0 0 0.0 1 34 51.6 0 0 0.0 7.2 da0 4 9 1 3 133.3 9 186 53.3 0 0 0.0 32.9 mmcsd0s3 3 9 0 0 0.0 9 186 53.3 0 0 0.0 32.9 mmcsd0s3a 1 1 1 3 133.3 0 0 0.0 0 0 0.0 8.0 mmcsd0s3b 1 1 0 0 0.0 1 34 51.7 0 0 0.0 7.2 da0a Thu Jun 28 02:34:11 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 37736 1010840 4% Jun 28 02:35:15 www kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted Jun 28 02:35:15 www kernel: g_vfs_done():da0a[WRITE(offset=827129856, length=16384)]error = 5 dT: 10.002s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 38 38 452 285.2 0 0 0.0 0 0 0.0 35.3 mmcsd0 0 38 38 456 286.1 0 0 0.0 0 0 0.0 35.5 mmcsd0s3 0 38 38 456 286.3 0 0 0.0 0 0 0.0 35.5 mmcsd0s3b Thu Jun 28 02:40:26 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 58408 990168 6% Jun 28 02:40:15 www kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 28 02:40:15 www kernel: (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain dT: 10.002s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name Thu Jun 28 02:40:37 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 58408 990168 6% Jun 28 02:40:15 www kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 28 02:40:15 www kernel: (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain dT: 10.076s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name Thu Jun 28 02:40:50 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 58408 990168 6% Jun 28 02:41:38 www kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 18 a6 80 00 00 40 00 Jun 28 02:41:38 www kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 28 02:41:38 www kernel: (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain Jun 28 02:41:38 www kernel: smsc0: warning: Failed to read register 0x114 Jun 28 02:41:38 www kernel: smsc0: warning: MII read timeout [da0 error flood continues] Curiously, the machine kept running (top output updated) until the plug was pulled next morning. This test is certainly quicker than using -j4 buildworld, but it isn't obvious it's doing the same thing since /dev/da0 is exercised far less. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Fri Jun 29 12:31:40 2018 Return-Path: Delivered-To: freebsd-arm@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 263101039EA9 for ; Fri, 29 Jun 2018 12:31:40 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D9D589A0F for ; Fri, 29 Jun 2018 12:31:38 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5TCSPt3070315 for ; Fri, 29 Jun 2018 22:28:25 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments To: freebsd-arm@freebsd.org References: <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> <20180628163328.GA33408@www.zefox.net> From: Trev Message-ID: <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> Date: Fri, 29 Jun 2018 22:28:25 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180628163328.GA33408@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Fri, 29 Jun 2018 22:28:25 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 12:31:40 -0000 Jun 29 20:20:35 rpi3 kernel: pid 66844 (c++), uid 0, was killed: out of swap space At the time of "out of swap" only 157M of the 4G swap was in use. The 4GB swap partition is on a 4GB USB2 memory key (da1p1), everything else is on the sdcard. There are no excessively long ms/w being recorded. There are no USB or other related errors. top and gstat stats leading up to the process being killed are below. last pid: 66931; load averages: 3.23, 3.14, 3.25 up 0+03:18:04 20:20:16 47 processes: 3 running, 44 sleeping Mem: 647M Active, 25M Inact, 22M Laundry, 188M Wired, 97M Buf, 19M Free Swap: 4044M Total, 136M Used, 3908M Free, 3% Inuse 1 15 0 0 0.0 15 607 65.0 97.4 mmcsd0s2a 4 17 7 56 2.0 10 120 8.9 4.2 da1p1 last pid: 66936; load averages: 3.29, 3.16, 3.25 up 0+03:18:08 20:20:20 47 processes: 4 running, 43 sleeping Mem: 664M Active, 5732K Inact, 27M Laundry, 184M Wired, 97M Buf, 19M Free Swap: 4044M Total, 138M Used, 3906M Free, 3% Inuse 1 13 0 0 0.0 13 527 58.8 74.7 mmcsd0s2a 4 34 2 20 2.9 32 2187 40.4 40.8 da1p1 last pid: 66941; load averages: 3.35, 3.17, 3.25 up 0+03:18:13 20:20:25 47 processes: 3 running, 44 sleeping Mem: 644M Active, 524K Inact, 58M Laundry, 183M Wired, 97M Buf, 15M Free Swap: 4044M Total, 140M Used, 3904M Free, 3% Inuse 0 3 0 0 0.0 3 96 98.0 29.1 mmcsd0s2a 5 42 0 0 0.0 42 2205 88.9 99.8 da1p1 last pid: 66946; load averages: 3.32, 3.17, 3.25 up 0+03:18:17 20:20:29 47 processes: 3 running, 44 sleeping Mem: 601M Active, 420K Inact, 96M Laundry, 184M Wired, 97M Buf, 20M Free Swap: 4044M Total, 150M Used, 3893M Free, 3% Inuse 1 1 0 0 0.0 1 96 169.5 16.9 mmcsd0s2a 0 102 5 32 158.3 97 1357 38.2 93.8 da1p1 last pid: 66951; load averages: 3.38, 3.18, 3.26 up 0+03:18:21 20:20:33 47 processes: 3 running, 44 sleeping Mem: 271M Active, 339M Inact, 89M Laundry, 184M Wired, 97M Buf, 18M Free Swap: 4044M Total, 157M Used, 3887M Free, 3% Inuse 0 7 0 0 0.0 7 223 79.4 55.4 mmcsd0s2a 5 0 0 0 0.0 0 0 0.0 0.0 da1p1 [OUT OF SWAP OCCURS HERE at 20:20:35 - 2 secs after the above and 2 secs before the below] last pid: 66957; load averages: 3.34, 3.18, 3.25 up 0+03:18:25 20:20:37 47 processes: 3 running, 44 sleeping Mem: 233M Active, 680K Inact, 296M Laundry, 184M Wired, 98M Buf, 187M Free Swap: 4044M Total, 157M Used, 3887M Free, 3% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 6 0 0 0 0.0 0 0 0.0 0.0 da1p1 From owner-freebsd-arm@freebsd.org Fri Jun 29 14:35:35 2018 Return-Path: Delivered-To: freebsd-arm@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 45506EF93CE for ; Fri, 29 Jun 2018 14:35:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 CDE368D72F for ; Fri, 29 Jun 2018 14:35:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Oa0lghcVM1l5s3eu7BV0bFaXS8EqSbXdBqTqVNdRPbE_8oZS.xc42.Wa67XLbYT SB2x7H25KE1QBPt3q.6OGTggG7L7EszrcjfqZOVVFr9RgpIs.MBD66p3p1phSdj_lN1ir661GQXx RZlhzzkdXcyML10aS5MocOuyZi.SfrEDVGvifbpG6fto9x67STCLt.e1pwY7kdkFhC63vhRSkwMR AdHzprKkPugQoUFqKeiK9M80gjtQ1cPMOftAJI3Iio6SNb6FRVaxtMlS2AN.6SOjieqSswysCCSI UCjHTsqFlM7bCCmbRIsIiR_lJ45lTD3yQ.UTLWojVmowRlrbNEpqgpWfL15Rs_E6bkQa33J7Ukob QjORvwqDAlGY3Zqb9IXqDczxgdbsVtjs_lCwKE9Nby3EkhNUCqkbEBqfhgilIk_b.xhZRYORWUfm 76PCRWKrAzVM0HTTSCXYAmJByIzHZv1YHrNhlbJK.LjlO1L6J_WH7gOuESgsj0utxNa9eb15dZ2Q e5K1ZQXTrqbQyuBlhAaN1doqUoD0djFbOTHthDWoydszYkuVsjME079QP7kwzHDRRnE9imVmqUed 8op74FND8rZPB_TWNsHecKON4H0771XRqfrcTmDCJix77UD3azSEiFR.RLpT3vhJXxIhkJK1fEGD jnWzkSbFR.BY5xbRjwD4aaP.HlBMkaUvtEdpZTepNdU7tvJutN7MltbmKjPa93M1If4df3xNkzwc 4eVHsAkCYU3fwbDO13xyCz4H4EfohHBMvIzydJ_W4hhlw8fIryb3jGogP7OKG4cvFcdqN5QfzqLt 8OxV4PIyGSDtMF7YIFJN64RyCo96R6gTEESYyzNuHUeO3pJCw_I1XGvgLhDGHVPboWy0AxKR_kGM Ora10X0aYALhv_zOLVf6bC6sbv.BXBia0_fG.jzoAkfUMj3YaSnvghXWnOqxFai9GbgdkbfMFNP8 3ATpzCIOhr8Ho_VBt7aeCvBXrq5tGte9jD2VJ4b7R0oUhg_Hra3Sa_1LqT6cP02Zp3vahpQM45RA - Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Fri, 29 Jun 2018 14:35:26 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d3d30051b609e3629cfb4a09a894b180; Fri, 29 Jun 2018 14:35:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> Date: Fri, 29 Jun 2018 07:35:19 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <67948AB1-DF97-4F4D-B6A4-3F858DF62750@yahoo.com> References: <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> <20180628163328.GA33408@www.zefox.net> <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> To: Trev X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 14:35:35 -0000 On 2018-Jun-29, at 5:28 AM, Trev wrote: > Jun 29 20:20:35 rpi3 kernel: pid 66844 (c++), uid 0, was killed: out = of swap space >=20 > At the time of "out of swap" only 157M of the 4G swap was in use. The = 4GB swap partition is on a 4GB USB2 memory key (da1p1), everything else = is on the sdcard. There are no excessively long ms/w being recorded. = There are no USB or other related errors. Good to know. > top and gstat stats leading up to the process being killed are below. >=20 > last pid: 66931; load averages: 3.23, 3.14, 3.25 up 0+03:18:04 = 20:20:16 > 47 processes: 3 running, 44 sleeping >=20 > Mem: 647M Active, 25M Inact, 22M Laundry, 188M Wired, 97M Buf, 19M = Free > Swap: 4044M Total, 136M Used, 3908M Free, 3% Inuse > 1 15 0 0 0.0 15 607 65.0 97.4 = mmcsd0s2a > 4 17 7 56 2.0 10 120 8.9 4.2 da1p1 >=20 > last pid: 66936; load averages: 3.29, 3.16, 3.25 up 0+03:18:08 = 20:20:20 > 47 processes: 4 running, 43 sleeping >=20 > Mem: 664M Active, 5732K Inact, 27M Laundry, 184M Wired, 97M Buf, 19M = Free > Swap: 4044M Total, 138M Used, 3906M Free, 3% Inuse > 1 13 0 0 0.0 13 527 58.8 74.7 = mmcsd0s2a > 4 34 2 20 2.9 32 2187 40.4 40.8 da1p1 >=20 > last pid: 66941; load averages: 3.35, 3.17, 3.25 up 0+03:18:13 = 20:20:25 > 47 processes: 3 running, 44 sleeping >=20 > Mem: 644M Active, 524K Inact, 58M Laundry, 183M Wired, 97M Buf, 15M = Free > Swap: 4044M Total, 140M Used, 3904M Free, 3% Inuse > 0 3 0 0 0.0 3 96 98.0 29.1 = mmcsd0s2a > 5 42 0 0 0.0 42 2205 88.9 99.8 da1p1 >=20 > last pid: 66946; load averages: 3.32, 3.17, 3.25 up 0+03:18:17 = 20:20:29 > 47 processes: 3 running, 44 sleeping >=20 > Mem: 601M Active, 420K Inact, 96M Laundry, 184M Wired, 97M Buf, 20M = Free > Swap: 4044M Total, 150M Used, 3893M Free, 3% Inuse > 1 1 0 0 0.0 1 96 169.5 16.9 = mmcsd0s2a > 0 102 5 32 158.3 97 1357 38.2 93.8 da1p1 >=20 > last pid: 66951; load averages: 3.38, 3.18, 3.26 up 0+03:18:21 = 20:20:33 > 47 processes: 3 running, 44 sleeping >=20 > Mem: 271M Active, 339M Inact, 89M Laundry, 184M Wired, 97M Buf, 18M = Free > Swap: 4044M Total, 157M Used, 3887M Free, 3% Inuse > 0 7 0 0 0.0 7 223 79.4 55.4 = mmcsd0s2a > 5 0 0 0 0.0 0 0 0.0 0.0 da1p1 >=20 > [OUT OF SWAP OCCURS HERE at 20:20:35 - 2 secs after the above and 2 = secs before the below] >=20 > last pid: 66957; load averages: 3.34, 3.18, 3.25 up 0+03:18:25 = 20:20:37 > 47 processes: 3 running, 44 sleeping >=20 > Mem: 233M Active, 680K Inact, 296M Laundry, 184M Wired, 98M Buf, 187M = Free > Swap: 4044M Total, 157M Used, 3887M Free, 3% Inuse > 0 0 0 0 0.0 0 0 0.0 0.0 = mmcsd0s2a > 6 0 0 0 0.0 0 0 0.0 0.0 da1p1 Just for reference/context: uname -apKU output? How would someone repeat your steps to set up and start a similar test? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jun 29 15:51:18 2018 Return-Path: Delivered-To: freebsd-arm@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 8E09DEFBD34 for ; Fri, 29 Jun 2018 15:51:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 049C88FDFA for ; Fri, 29 Jun 2018 15:51:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5TFpVKK038385 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jun 2018 08:51:32 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5TFpVJB038384; Fri, 29 Jun 2018 08:51:31 -0700 (PDT) (envelope-from fbsd) Date: Fri, 29 Jun 2018 08:51:31 -0700 From: bob prohaska To: Trev Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180629155131.GA35717@www.zefox.net> References: <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> <20180628163328.GA33408@www.zefox.net> <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 15:51:18 -0000 On Fri, Jun 29, 2018 at 10:28:25PM +1000, Trev wrote: > > Jun 29 20:20:35 rpi3 kernel: pid 66844 (c++), uid 0, was killed: out of > swap space > > At the time of "out of swap" only 157M of the 4G swap was in use. The > 4GB swap partition is on a 4GB USB2 memory key (da1p1), everything else > is on the sdcard. There are no excessively long ms/w being recorded. > There are no USB or other related errors. > That's a little surprising, and disturbing. By my experience your setup should have run to completion. Do you see a "too much swap" complaint? I don't know if it's a problem, but 4 GB of swap triggers one on my RPi3. 3 GB does not. 2 GB is enough to finish -j4 buildworld. [snip] Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Fri Jun 29 22:54:26 2018 Return-Path: Delivered-To: freebsd-arm@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 96B8AFD0C0E for ; Fri, 29 Jun 2018 22:54:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BF11880272 for ; Fri, 29 Jun 2018 22:54:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5TMsX3G043603 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jun 2018 15:54:34 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5TMsX7s043602; Fri, 29 Jun 2018 15:54:33 -0700 (PDT) (envelope-from fbsd) Date: Fri, 29 Jun 2018 15:54:33 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments Message-ID: <20180629225433.GB35717@www.zefox.net> References: <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 22:54:26 -0000 On Wed, Jun 27, 2018 at 06:12:53PM -0700, Mark Millard wrote: > > It would be handy for something simpler than buildworld to be > able to induce some of the types of problems, for sure. > It appears that running root@www:/home/bob/stress2/misc # sh ./snap.sh > 5thstress2.log & triggers a stream of console errors that resemble those produced by -j4 buildworld: GEOM: md10: invalid disklabel. GEOM: ufsid/5a5a128b05c5944d: invalid disklabel. (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 18 a9 80 00 00 30 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 18 a9 80 00 00 30 00 The error stream continues until powercycling, escape to debugger does not work. To some extent, the machine remains responsive in ssh sessions, at least for simple commands (ls -l, tail). The stress2 logfile is empty. The details captured are visible at http://www.zefox.net/~fbsd/rpi3/swaptests/r335655/1gbsdflash/stress2/5thtest/ One oddity is a stream of indisplayable characters, briefly, in http://www.zefox.net/~fbsd/rpi3/swaptests/r335655/1gbsdflash/stress2/5thtest/5thswapuse.log following the initial error message. Another oddity is that during a single user reboot similar errors are briefly displayed before starting the shell. After two rounds of fsck -f they seem to vanish, not to return without appropriate provocation. This does not happen on every reboot, but enough to be no-longer surprising. It looks as if this particular error message has nothing at all to do with swap. Does it seem in any way related to similar errors seen during swap-stressed buildworld sessions? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Fri Jun 29 23:00:20 2018 Return-Path: Delivered-To: freebsd-arm@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 BA3C9FD2093 for ; Fri, 29 Jun 2018 23:00:19 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF8EB803BA for ; Fri, 29 Jun 2018 23:00:18 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5TN0E41020344 for ; Sat, 30 Jun 2018 09:00:15 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments To: freebsd-arm@freebsd.org References: <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> <20180628163328.GA33408@www.zefox.net> <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> <67948AB1-DF97-4F4D-B6A4-3F858DF62750@yahoo.com> From: Trev Message-ID: <93fcbb50-01b7-9a14-419a-ca3f157dbde7@sentry.org> Date: Sat, 30 Jun 2018 09:00:14 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <67948AB1-DF97-4F4D-B6A4-3F858DF62750@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Sat, 30 Jun 2018 09:00:15 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 23:00:20 -0000 Mark Millard wrote on 30/06/2018 00:35: > > > On 2018-Jun-29, at 5:28 AM, Trev wrote: > > >> Jun 29 20:20:35 rpi3 kernel: pid 66844 (c++), uid 0, was killed: out of swap space >> >> At the time of "out of swap" only 157M of the 4G swap was in use. The 4GB swap partition is on a 4GB USB2 memory key (da1p1), everything else is on the sdcard. There are no excessively long ms/w being recorded. There are no USB or other related errors. > > Good to know. > >> top and gstat stats leading up to the process being killed are below. >> >> last pid: 66931; load averages: 3.23, 3.14, 3.25 up 0+03:18:04 20:20:16 >> 47 processes: 3 running, 44 sleeping >> >> Mem: 647M Active, 25M Inact, 22M Laundry, 188M Wired, 97M Buf, 19M Free >> Swap: 4044M Total, 136M Used, 3908M Free, 3% Inuse >> 1 15 0 0 0.0 15 607 65.0 97.4 mmcsd0s2a >> 4 17 7 56 2.0 10 120 8.9 4.2 da1p1 >> >> last pid: 66936; load averages: 3.29, 3.16, 3.25 up 0+03:18:08 20:20:20 >> 47 processes: 4 running, 43 sleeping >> >> Mem: 664M Active, 5732K Inact, 27M Laundry, 184M Wired, 97M Buf, 19M Free >> Swap: 4044M Total, 138M Used, 3906M Free, 3% Inuse >> 1 13 0 0 0.0 13 527 58.8 74.7 mmcsd0s2a >> 4 34 2 20 2.9 32 2187 40.4 40.8 da1p1 >> >> last pid: 66941; load averages: 3.35, 3.17, 3.25 up 0+03:18:13 20:20:25 >> 47 processes: 3 running, 44 sleeping >> >> Mem: 644M Active, 524K Inact, 58M Laundry, 183M Wired, 97M Buf, 15M Free >> Swap: 4044M Total, 140M Used, 3904M Free, 3% Inuse >> 0 3 0 0 0.0 3 96 98.0 29.1 mmcsd0s2a >> 5 42 0 0 0.0 42 2205 88.9 99.8 da1p1 >> >> last pid: 66946; load averages: 3.32, 3.17, 3.25 up 0+03:18:17 20:20:29 >> 47 processes: 3 running, 44 sleeping >> >> Mem: 601M Active, 420K Inact, 96M Laundry, 184M Wired, 97M Buf, 20M Free >> Swap: 4044M Total, 150M Used, 3893M Free, 3% Inuse >> 1 1 0 0 0.0 1 96 169.5 16.9 mmcsd0s2a >> 0 102 5 32 158.3 97 1357 38.2 93.8 da1p1 >> >> last pid: 66951; load averages: 3.38, 3.18, 3.26 up 0+03:18:21 20:20:33 >> 47 processes: 3 running, 44 sleeping >> >> Mem: 271M Active, 339M Inact, 89M Laundry, 184M Wired, 97M Buf, 18M Free >> Swap: 4044M Total, 157M Used, 3887M Free, 3% Inuse >> 0 7 0 0 0.0 7 223 79.4 55.4 mmcsd0s2a >> 5 0 0 0 0.0 0 0 0.0 0.0 da1p1 >> >> [OUT OF SWAP OCCURS HERE at 20:20:35 - 2 secs after the above and 2 secs before the below] >> >> last pid: 66957; load averages: 3.34, 3.18, 3.25 up 0+03:18:25 20:20:37 >> 47 processes: 3 running, 44 sleeping >> >> Mem: 233M Active, 680K Inact, 296M Laundry, 184M Wired, 98M Buf, 187M Free >> Swap: 4044M Total, 157M Used, 3887M Free, 3% Inuse >> 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a >> 6 0 0 0 0.0 0 0 0.0 0.0 da1p1 > > Just for reference/context: > > uname -apKU > > output? % uname -apKU FreeBSD rpi3.sentry.org 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r335317: Mon Jun 18 17:37:04 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 aarch64 1200069 1200069 FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180618-r335317.img at: https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20180618-r335317.img.xz > How would someone repeat your steps to set up > and start a similar test? % cat /etc/fstab # Custom /etc/fstab for FreeBSD embedded images /dev/ufs/rootfs / ufs rw,noatime 1 1 /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 md1 /tmp mfs rw,noatime,-s100m 0 0 md2 /var/log mfs rw,noatime,-s15m 0 0 md3 /var/tmp mfs rw,noatime,-s15m 0 0 /dev/da1p1 none swap sw 0 0 #/dev/ufs/usr /usr ufs rw,noatime 2 2 16GB SanDisk Ultra micro sdcard (12 current snapshot from 18 June): % gpart show -l mmcsd => 63 31116225 mmcsd0 MBR (15G) 63 2016 - free - (1.0M) 2079 102312 1 (null) [active] (50M) 104391 31008825 2 (null) (15G) 31113216 3072 - free - (1.5M) % gpart show -l mmcsd0s2 => 0 31008825 mmcsd0s2 BSD (15G) 0 57 - free - (29K) 57 31008768 1 (null) (15G) % gpart show -l da1 => 40 8282032 da1 GPT (3.9G) 40 8282032 1 usbswap (3.9G) Promotional 4GB USB2 memory key from UNSW Law Faculty :) da1: Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 4044MB (8282112 512 byte sectors) da1: quirks=0x2 From owner-freebsd-arm@freebsd.org Fri Jun 29 23:05:26 2018 Return-Path: Delivered-To: freebsd-arm@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 D8F79FD2471 for ; Fri, 29 Jun 2018 23:05:26 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E966280711 for ; Fri, 29 Jun 2018 23:05:25 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5TN5M28020633 for ; Sat, 30 Jun 2018 09:05:22 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments To: freebsd-arm@freebsd.org References: <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> <20180628163328.GA33408@www.zefox.net> <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> <20180629155131.GA35717@www.zefox.net> From: Trev Message-ID: Date: Sat, 30 Jun 2018 09:05:22 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180629155131.GA35717@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Sat, 30 Jun 2018 09:05:22 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 23:05:27 -0000 bob prohaska wrote on 30/06/2018 01:51: > On Fri, Jun 29, 2018 at 10:28:25PM +1000, Trev wrote: >> >> Jun 29 20:20:35 rpi3 kernel: pid 66844 (c++), uid 0, was killed: out of >> swap space >> >> At the time of "out of swap" only 157M of the 4G swap was in use. The >> 4GB swap partition is on a 4GB USB2 memory key (da1p1), everything else >> is on the sdcard. There are no excessively long ms/w being recorded. >> There are no USB or other related errors. >> > > That's a little surprising, and disturbing. By my experience your setup > should have run to completion. > > Do you see a "too much swap" complaint? I don't know if it's a problem, > but 4 GB of swap triggers one on my RPi3. 3 GB does not. 2 GB is enough > to finish -j4 buildworld. Indeed, yes: warning: total configured swap (1035254 pages) exceeds maximum recommended amount (921968 pages). warning: increase kern.maxswzone or reduce amount of swap. (I get a similar warning for the RPi2B which has 2GB of swap, but uses 1.4G+ peak during a -j4 buildworld and always completes successfully.) I'll reduce it to 2G and see what happens in 5 hours... From owner-freebsd-arm@freebsd.org Fri Jun 29 23:37:52 2018 Return-Path: Delivered-To: freebsd-arm@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 41883FD3719 for ; Fri, 29 Jun 2018 23:37:52 +0000 (UTC) (envelope-from wlosh@bsdimp.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 C3DCB8139E for ; Fri, 29 Jun 2018 23:37:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id y127-v6so3591014itd.1 for ; Fri, 29 Jun 2018 16:37:51 -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=UYKpjr3INbwl2CjK1rdoZN7ZaZga2tuaymdarEPyNyQ=; b=FISQnu37ydNnJk8NLTu0QqYSU190DdcPzmwi55ILbp4gh665BjmqLQKAgwBB+9VFb0 3Pwr2jfBcGEvtIC48pEzFtbCWxWTxJu1eh/CDUeI2BtZRYt5DkX8gGrWOYWFtqejCz19 JhVXLdu79FfoGBOXUqAzKsf6CRNuhCnHqfa9RdP0Lux+pLc5hfdGssWYHc2hD/IOsJc/ ALQ11mX8ayEFHKAP8UfuX/zQTMtnFYuEJjLoe5l6Af6l7JyDGlmeVjFPAQMZoFdJ8xjs B3Y3tFnFBxsSoMBuE1qP5a+KRAn1DJaWCxzBU2EzEyEBEkyjnijGCW49++9d3el8lMav IMCw== 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=UYKpjr3INbwl2CjK1rdoZN7ZaZga2tuaymdarEPyNyQ=; b=bjWby4bMDOh04fiS/iurcyYUs9qft0MEZTuBwkLaWKt5FqOx1XP1e7se9Jn543/5GY E9MA7KcucETZk8o4B+UI2MsuD2MdbjroZKzXaeyhQ+/3fPXqOxCU8NDxcqlEVw2YWPEM DV87wmXMvdaUhbW/HoAKnBQCsu+LSzYz+7nQBtHdk5NYrn+kmSk+nOfSCsQxMp1Lzm2Z z+PJfJex/ly9xnHi3zsVHBciaKOLGhuY8x98s1Ps56t2STrrV5ZUTK7lh42RhRdUJXBh HJT4Mmz5FwQF7pt1up70VrZsFlRpcKQnVEFJN06/qoNZTHwCHJDLgCD3o50998bn1q07 FPQg== X-Gm-Message-State: APt69E2JltJBEZZTCXHiccO/4qS2xgaMm4VLedp2WFfQxiF40Fbhi7y+ mKaklnsAuHwLbnn9VLN3U3uaYuo5W3XpibUlp6QwHw== X-Google-Smtp-Source: AAOMgpech3RjHUfIjI1yPW9m1HdPROQTs9YzKriJ8Jf2tyCrRt0+F2CtB1xrv6140GKpyo9sDGeAOm/8o2QfvQow67E= X-Received: by 2002:a24:7c8d:: with SMTP id a135-v6mr3379397itd.73.1530315470948; Fri, 29 Jun 2018 16:37:50 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Fri, 29 Jun 2018 16:37:50 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180629225433.GB35717@www.zefox.net> References: <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180629225433.GB35717@www.zefox.net> From: Warner Losh Date: Fri, 29 Jun 2018 17:37:50 -0600 X-Google-Sender-Auth: 1wtEwgx_piMXfJjH-X3v3CE0hfc Message-ID: Subject: Re: RPI3 swap experiments To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 23:37:52 -0000 On Fri, Jun 29, 2018 at 4:54 PM, bob prohaska wrote: > On Wed, Jun 27, 2018 at 06:12:53PM -0700, Mark Millard wrote: > > > > It would be handy for something simpler than buildworld to be > > able to induce some of the types of problems, for sure. > > > > It appears that running > root@www:/home/bob/stress2/misc # sh ./snap.sh > 5thstress2.log & > triggers a stream of console errors that resemble those produced > by -j4 buildworld: > > GEOM: md10: invalid disklabel. > GEOM: ufsid/5a5a128b05c5944d: invalid disklabel. > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 18 a9 80 00 00 30 00 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 18 a9 80 00 00 30 00 > The drive is broken somewhere at or below the SIM. Reasonable write requests from CAM's periph da are being rejected. This tells me there's a problem. In this case, the SIM is umass which additionally has the USB stack under it. If I had to wager, I'd wager more on the USB driver being wonky than umass. Something is happening, and the SIM is returning an error to the periph. You're next step in tracking this down would be to see why by instrumenting umass' xpt_done calls that complete the CCBs that are queued by the sim's action routine. The error stream continues until powercycling, escape to debugger does > not work. To some extent, the machine remains responsive in ssh sessions, > at least for simple commands (ls -l, tail). The stress2 logfile is empty. > Yes. Something early in this sequence breaks the drive. Since the errors are CAM errors like this, they are at the umass-sim0 layer or lower. > The details captured are visible at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335655/ > 1gbsdflash/stress2/5thtest/ > > One oddity is a stream of indisplayable characters, briefly, in > http://www.zefox.net/~fbsd/rpi3/swaptests/r335655/ > 1gbsdflash/stress2/5thtest/5thswapuse.log > following the initial error message. > > Another oddity is that during a single user reboot similar errors are > briefly > displayed before starting the shell. After two rounds of fsck -f they seem > to > vanish, not to return without appropriate provocation. This does not > happen on > every reboot, but enough to be no-longer surprising. > > It looks as if this particular error message has nothing at all to do with > swap. > Does it seem in any way related to similar errors seen during swap-stressed > buildworld sessions? Looks like the same to me, and I have the same diagnosis. Warner > > Thanks for reading, > > bob prohaska > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sat Jun 30 00:00:15 2018 Return-Path: Delivered-To: freebsd-arm@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 75EEEFD49E8 for ; Sat, 30 Jun 2018 00:00:15 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DBF581DF0 for ; Sat, 30 Jun 2018 00:00:14 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5U00AMT024034 for ; Sat, 30 Jun 2018 10:00:10 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments To: freebsd-arm@freebsd.org References: <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> <20180628163328.GA33408@www.zefox.net> <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> <20180629155131.GA35717@www.zefox.net> <20180629233937.GC35717@www.zefox.net> From: Trev Message-ID: <0f137e06-214a-3e8c-a216-f061ec04ac2c@sentry.org> Date: Sat, 30 Jun 2018 10:00:10 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180629233937.GC35717@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Sat, 30 Jun 2018 10:00:10 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 00:00:15 -0000 bob prohaska wrote on 30/06/2018 09:39: >> (I get a similar warning for the RPi2B which has 2GB of swap, but uses >> 1.4G+ peak during a -j4 buildworld and always completes successfully.) > Are you sure the peak swap use is that high? Last time I ran -j4 buildworld > on my 11-stable Pi2 the swapinfo line with the highest usage was > /dev/da0b 2097152 322264 1774888 15% > or 322 MB. > > The two needn't be the same, but I'd expect them to be closer than that. 1.424G to be precise. System was multi-user. I may have had X running too, not absolutely sure. >> I'll reduce it to 2G and see what happens in 5 hours... > In my notes I don't find an RPi3 test case for 2GB swap, only 1, 2.3 and 3. > I _think_ 2 GB is enough, based on a ~1.4 GB peak, but apparently didn't test it. > Apologies for the misinformation! Not a problem. > I'm very curious to see if it makes a difference. You've already > surprised me once......8-) We'll see :) From owner-freebsd-arm@freebsd.org Sat Jun 30 01:52:14 2018 Return-Path: Delivered-To: freebsd-arm@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 E5A52FDFFD5 for ; Sat, 30 Jun 2018 01:52:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 63A7B85F59 for ; Sat, 30 Jun 2018 01:52:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5U1qQ4u044158 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jun 2018 18:52:27 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5U1qPR3044157; Fri, 29 Jun 2018 18:52:25 -0700 (PDT) (envelope-from fbsd) Date: Fri, 29 Jun 2018 18:52:25 -0700 From: bob prohaska To: Warner Losh Cc: "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180630015225.GB43801@www.zefox.net> References: <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180629225433.GB35717@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 01:52:14 -0000 On Fri, Jun 29, 2018 at 05:37:50PM -0600, Warner Losh wrote: > > > The drive is broken somewhere at or below the SIM. Reasonable write > requests from CAM's periph da are being rejected. This tells me there's a > problem. In this case, the SIM is umass which additionally has the USB > stack under it. If I had to wager, I'd wager more on the USB driver being > wonky than umass. Something is happening, and the SIM is returning an error > to the periph. You're next step in tracking this down would be to see why > by instrumenting umass' xpt_done calls that complete the CCBs that are > queued by the sim's action routine. > By "instrumenting" I don't think you mean wires and 'scopes......dtrace, maybe? It's clear this is over my head, but I'll ask a further indulgence. Using figure 2 at https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf or a better one if it exists, where on the diagram would the problem likely be? It's pretty clear userland is up and copper stuff is down. Is USB even on the same piece of paper? There's no hope I can fix anything, but would be happy to test if it helps. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sat Jun 30 22:18:08 2018 Return-Path: Delivered-To: freebsd-arm@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 3D3FEFDD794 for ; Sat, 30 Jun 2018 22:18:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 920BE8EF44 for ; Sat, 30 Jun 2018 22:18:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5UMILed048565 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Jun 2018 15:18:22 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5UMILVp048564; Sat, 30 Jun 2018 15:18:21 -0700 (PDT) (envelope-from fbsd) Date: Sat, 30 Jun 2018 15:18:21 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: devmatch: Malformed NOMATCH string: '$' Message-ID: <20180630221821.GA47792@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 22:18:08 -0000 In booting up a new snapshot for the rpi3 dated June 28 a message on the console says devmatch: Malformed NOMATCH string: '$' which repeats perhaps twenty times and then goes away. >From the man page it seems fairly harmless. Is this correct? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sat Jun 30 23:07:09 2018 Return-Path: Delivered-To: freebsd-arm@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 D339EFDE706 for ; Sat, 30 Jun 2018 23:07:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 4CBBC900DF for ; Sat, 30 Jun 2018 23:07:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id i23-v6so11601750iog.10 for ; Sat, 30 Jun 2018 16:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yIP343S1z/Yzrg65cVrttAsT/PhDTAc37I2ovjo6EqA=; b=VNlHF/ISkYrnyVTqQB4rDFEf64ZtNgXIQnuH/DZYmLvdMho5tw/QOqCyD27zkOLWA/ HDwMpr8SkOEDbt1fi703wJnwtYBwTGCVqRessb0EOvpTh7EYZ7jo+s1OsKRdgJOQiS+6 0tGKTz+bl4lF1jahY5n87QJZjJ5yNcGwmxQr/4w2w/QH/N+kQrmb6ZftekxytrJrA6pk IaK4e82VOiJm3TQn/xSFycWVUU3US7GktyGjTaUkkaFDa4XHiN1qW2tMRBQZqfB0W7Ic 1A/SW0RvdINgP7ddYLtpKe/7QJOe+RpfTZ2Lm1YZOYE8/F1mhBtgURcJdKAs9cICvAA+ 6TLQ== 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=yIP343S1z/Yzrg65cVrttAsT/PhDTAc37I2ovjo6EqA=; b=IJVfgjlx0q3/9pB6nGPJ+yPg1nhJR5D1OZ4on/qrHiH0ilDCRyxN99JSjii5c1Meeg 8K2rKfQ1Ypjt/mMFZ6MZ6LoLe/SjyYMFK0RWvTBlQ8WfZa9TULbOnfHPsmjTrSTE/i1c RVQOhAG1VSvzjgE3YFSyOjuctY3eoGEXy/E4aHb/gwGFMa6DRlSEWiRLHWC//whw7r/U cpOc/0Q6vmvMxX2saojrrAQMgJDkw9NG2ki1yWRGoSndHZIWD/G5jAYpzcOBfR0a2G3O q2hKFMmF2Szt32HJAkT38EiCTIoRdfgYkH1XH7enfIftjG0hKGK7wT5dH5DoFDGudW9Z dsiw== X-Gm-Message-State: APt69E25mgYiKpgkJnKMaldaIkGLJcgj00D6zcJhi8qc82eCM+7KMdj0 KcLcKIv93plA/iVNwf3NamnYSwvVwD5VSUInYRrb2w== X-Google-Smtp-Source: AAOMgpe7PaB530SEwM2wkvij7DlMoY1aKLpwMxtEipDJtwdVDLsMZfM4szrqNXoRAFgYuJWZmY6bxsXiPepDBX7/QyI= X-Received: by 2002:a6b:280a:: with SMTP id o10-v6mr16553455ioo.168.1530400027657; Sat, 30 Jun 2018 16:07:07 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Sat, 30 Jun 2018 16:07:06 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180630221821.GA47792@www.zefox.net> References: <20180630221821.GA47792@www.zefox.net> From: Warner Losh Date: Sat, 30 Jun 2018 17:07:06 -0600 X-Google-Sender-Auth: v9Xu8bwbGOV3JMvtLqTRSjgeKcE Message-ID: Subject: Re: devmatch: Malformed NOMATCH string: '$' To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 23:07:09 -0000 See UPDATING. I fixed this. Warner On Sat, Jun 30, 2018 at 4:18 PM, bob prohaska wrote: > In booting up a new snapshot for the rpi3 dated June 28 a message on the > console says > devmatch: Malformed NOMATCH string: '$' > which repeats perhaps twenty times and then goes away. > > From the man page it seems fairly harmless. Is this correct? > > Thanks for reading, > > bob prohaska > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sat Jun 30 23:21:01 2018 Return-Path: Delivered-To: freebsd-arm@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 96238FDEACE for ; Sat, 30 Jun 2018 23:21:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B5690511 for ; Sat, 30 Jun 2018 23:20:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5UNL3J2048738 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Jun 2018 16:21:04 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5UNL3io048737; Sat, 30 Jun 2018 16:21:03 -0700 (PDT) (envelope-from fbsd) Date: Sat, 30 Jun 2018 16:21:02 -0700 From: bob prohaska To: Warner Losh Cc: "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: devmatch: Malformed NOMATCH string: '$' Message-ID: <20180630232102.GB47792@www.zefox.net> References: <20180630221821.GA47792@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 23:21:01 -0000 On Sat, Jun 30, 2018 at 05:07:06PM -0600, Warner Losh wrote: > See UPDATING. I fixed this. > I'm halfway between chicken and egg at the moment and can't look yet. Will it keep until I can checkout a source tree? There may be quite a few reboots in the meantime. Thanks for reading! bob prohaska > Warner > > On Sat, Jun 30, 2018 at 4:18 PM, bob prohaska wrote: > > > In booting up a new snapshot for the rpi3 dated June 28 a message on the > > console says > > devmatch: Malformed NOMATCH string: '$' > > which repeats perhaps twenty times and then goes away. > > > > From the man page it seems fairly harmless. Is this correct? > > > > Thanks for reading, > > > > bob prohaska > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@freebsd.org Sat Jun 30 23:24:11 2018 Return-Path: Delivered-To: freebsd-arm@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 8E675FDECB0 for ; Sat, 30 Jun 2018 23:24:11 +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 10071907B0 for ; Sat, 30 Jun 2018 23:24:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id d185-v6so11639430ioe.0 for ; Sat, 30 Jun 2018 16:24: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=I6qBNEF9IlMuudCIxtI7w7UIypSKS/K9az7Pg0SYt68=; b=PpVW1j65ASJKl5qraxePtWu0StuynuqjovDBB9lP2oLPuzMAvzZTSOiv4ThC83fcQw 6eSPmbMJuw/LHDd5NOn3AZ7TDq6mL+uQoYbiCzqbMz+0w5FIAggwqEi21IPg4kQsQIvy MgU734vVbaAnpQlV/CxF1t+34X8HEL33oduYeHJK/ZOS/5rvQq5ZEwkA0SRblgZsdKXV mWAnVaTEq1VXhQ+d6a9SK5xaCYdLVUnJc7PIOMm668UhmoGyEWKc2aMvduBTOcXIL6ux eKk/NPxlRla9TuA5slsWJNT15sQEQVnOZAGYOptZnH+oq01mgAe83gQQTlOZvyAuX97Y 6QkQ== 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=I6qBNEF9IlMuudCIxtI7w7UIypSKS/K9az7Pg0SYt68=; b=Og9I8w++fA4WeBphYVOixttecIpa1rtPvh43m+maXJx+I3qHVmFYDdjz1PhZZRR/BL AkAwvQ31K5wkZYAvSYiTt6CkLSS9cyxDS9PcC3hylw65Tor0qFKPYsZPrSJv7qnn07dC IB3ZIyUyJh9HUPym6Epwp+rtgvzrEPNGQB4PxKPFK3cOqsdipXxpmbxsX0SnS0i2FTTB G8DeuwZBSWHYlENzEa3KSlm1mNcWZ9RKlgVEZWeoYiCSEMOnAXhgHyvKyi7IOsmtdOk5 cK7N0b25De5kH3kKsXyw9CbPcAS5NIPeL3hzAkNypmYi4c+CaJIF40mrP0nRweEmaSJh v9gA== X-Gm-Message-State: APt69E07S955DT08dYgQDRZZYNC+AAm3UtaIuJ6jyYhuOnU7yo2Qh2/f QBWur4sJCq8hgxbTiJAynfYw238qh5Xei+rvzhbTsg== X-Google-Smtp-Source: AAOMgpfxJ4wmbDf9Uf9WdR9cRAbJbjy27luamwEe23oPMmc59e9LxBEKPFzc2qBSwYKpD2FI0BlF7pM7S/USEQaPxow= X-Received: by 2002:a6b:d40c:: with SMTP id l12-v6mr3793531iog.37.1530401050232; Sat, 30 Jun 2018 16:24:10 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Sat, 30 Jun 2018 16:24:09 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180630232102.GB47792@www.zefox.net> References: <20180630221821.GA47792@www.zefox.net> <20180630232102.GB47792@www.zefox.net> From: Warner Losh Date: Sat, 30 Jun 2018 17:24:09 -0600 X-Google-Sender-Auth: 2ujYGDf0kh0cPmOzfZfEITacrEs Message-ID: Subject: Re: devmatch: Malformed NOMATCH string: '$' To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 23:24:11 -0000 On Sat, Jun 30, 2018 at 5:21 PM, bob prohaska wrote: > On Sat, Jun 30, 2018 at 05:07:06PM -0600, Warner Losh wrote: > > See UPDATING. I fixed this. > > > I'm halfway between chicken and egg at the moment and can't look yet. > Will it keep until I can checkout a source tree? There may be quite > a few reboots in the meantime. > Sure. You can ignore it, and kldload anything that you need by hand. Warner > Thanks for reading! > > bob prohaska > > > Warner > > > > On Sat, Jun 30, 2018 at 4:18 PM, bob prohaska > wrote: > > > > > In booting up a new snapshot for the rpi3 dated June 28 a message on > the > > > console says > > > devmatch: Malformed NOMATCH string: '$' > > > which repeats perhaps twenty times and then goes away. > > > > > > From the man page it seems fairly harmless. Is this correct? > > > > > > Thanks for reading, > > > > > > bob prohaska > > > > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > From owner-freebsd-arm@freebsd.org Sat Jun 30 23:42:26 2018 Return-Path: Delivered-To: freebsd-arm@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 9E693FDF17E for ; Sat, 30 Jun 2018 23:42:26 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D201290DD6 for ; Sat, 30 Jun 2018 23:42:25 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5UNgFlp061939 for ; Sun, 1 Jul 2018 09:42:15 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments To: freebsd-arm@freebsd.org References: <20180626222834.GA20270@www.zefox.net> <28012DFB-37A0-461A-BB62-CD3EE61E82F0@yahoo.com> <20180627054027.GA22144@www.zefox.net> <20180627194217.GA27793@www.zefox.net> <20180628022457.GA30110@www.zefox.net> <7B9D272D-3EDE-46FA-8A1C-AEE65047167C@yahoo.com> <20180628163328.GA33408@www.zefox.net> <51e208b4-9f14-58f7-1e70-6ef8db2c0bed@sentry.org> <20180629155131.GA35717@www.zefox.net> From: Trev Message-ID: Date: Sun, 1 Jul 2018 09:42:15 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180629155131.GA35717@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Sun, 01 Jul 2018 09:42:15 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 23:42:26 -0000 bob prohaska wrote on 30/06/2018 01:51: > On Fri, Jun 29, 2018 at 10:28:25PM +1000, Trev wrote: >> >> Jun 29 20:20:35 rpi3 kernel: pid 66844 (c++), uid 0, was killed: out of >> swap space >> >> At the time of "out of swap" only 157M of the 4G swap was in use. The >> 4GB swap partition is on a 4GB USB2 memory key (da1p1), everything else >> is on the sdcard. There are no excessively long ms/w being recorded. >> There are no USB or other related errors. >> > > That's a little surprising, and disturbing. By my experience your setup > should have run to completion. > > Do you see a "too much swap" complaint? I don't know if it's a problem, > but 4 GB of swap triggers one on my RPi3. 3 GB does not. 2 GB is enough > to finish -j4 buildworld. Jun 30 23:32:12 rpi3 kernel: pid 60735 (c++), uid 0, was killed: out of swap space No go with 2GB (I deleted the da0p1 swap partition; destroyed da0; then remade it it with a 2GB p1; then rebooted - no "too much swap" complaints). Out of swap with 56M of 2GB used. And this was with make -j2 buildworld. Here's the top and gstat stats leading up to, at the time of out of swap and just after: last pid: 61290; load averages: 2.42, 2.27, 2.19 up 0+12:23:41 23:32:07 33 processes: 2 running, 31 sleeping Mem: 609M Active, 296K Inact, 95M Laundry, 176M Wired, 97M Buf, 20M Free Swap: 2048M Total, 47M Used, 2001M Free, 2% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 4 68 0 0 0.0 68 1487 20.9 36.7 da0p1 last pid: 61294; load averages: 2.42, 2.27, 2.19 up 0+12:23:42 23:32:08 33 processes: 2 running, 31 sleeping Mem: 612M Active, 180K Inact, 94M Laundry, 176M Wired, 97M Buf, 19M Free Swap: 2048M Total, 49M Used, 1999M Free, 2% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 4 110 0 0 0.0 110 3653 24.3 77.8 da0p1 last pid: 61298; load averages: 2.42, 2.27, 2.19 up 0+12:23:43 23:32:09 33 processes: 2 running, 31 sleeping Mem: 614M Active, 248K Inact, 90M Laundry, 176M Wired, 97M Buf, 20M Free Swap: 2048M Total, 53M Used, 1995M Free, 2% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 0 28 0 0 0.0 28 2737 157.7 113.7 da0p1 last pid: 61302; load averages: 2.42, 2.27, 2.19 up 0+12:23:45 23:32:11 33 processes: 2 running, 31 sleeping Mem: 322M Active, 297M Inact, 88M Laundry, 176M Wired, 97M Buf, 17M Free Swap: 2048M Total, 55M Used, 1993M Free, 2% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 5 0 0 0 0.0 0 0 0.0 0.0 da0p1 last pid: 61306; load averages: 2.42, 2.27, 2.19 up 0+12:23:46 23:32:12 33 processes: 1 running, 32 sleeping Mem: 326M Active, 164K Inact, 379M Laundry, 176M Wired, 97M Buf, 19M Free Swap: 2048M Total, 56M Used, 1992M Free, 2% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 6 0 0 0 0.0 0 0 0.0 0.0 da0p1 last pid: 61310; load averages: 2.39, 2.27, 2.19 up 0+12:23:47 23:32:13 33 processes: 1 running, 32 sleeping Mem: 331M Active, 184K Inact, 379M Laundry, 176M Wired, 97M Buf, 14M Free Swap: 2048M Total, 56M Used, 1992M Free, 2% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 6 0 0 0 0.0 0 0 0.0 0.0 da0p1 [OUT OF SWAP at 23:32:14 captured immediately below] last pid: 61315; load averages: 2.39, 2.27, 2.19 up 0+12:23:48 23:32:14 33 processes: 1 running, 32 sleeping Mem: 78M Active, 176K Inact, 315M Laundry, 174M Wired, 97M Buf, 332M Free Swap: 2048M Total, 56M Used, 1992M Free, 2% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 0 48 37 710 126.2 11 1186 341.9 26.4 da0p1 last pid: 61320; load averages: 2.39, 2.27, 2.19 up 0+12:23:49 23:32:15 33 processes: 2 running, 31 sleeping Mem: 55M Active, 848K Inact, 1644K Laundry, 174M Wired, 97M Buf, 669M Free Swap: 2048M Total, 48M Used, 2000M Free, 2% Inuse 0 0 0 0 0.0 0 0 0.0 0.0 mmcsd0s2a 0 0 0 0 0.0 0 0 0.0 0.0 da0p1