From owner-freebsd-hackers@freebsd.org Sun Feb 7 17:50:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD307AA0352 for ; Sun, 7 Feb 2016 17:50:21 +0000 (UTC) (envelope-from bmvince1@asu.edu) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 79BCD1C84 for ; Sun, 7 Feb 2016 17:50:21 +0000 (UTC) (envelope-from bmvince1@asu.edu) Received: by mail-yw0-x233.google.com with SMTP id h129so87954546ywb.1 for ; Sun, 07 Feb 2016 09:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KiP18nVqCHEchA2QZqmRbJnRl4pUchHT5PRsgkgmC+A=; b=maP+mg3ZqnsrUmC+jEA911zgwuUOfhjn3XKQFYp1RrOJDo7PXSjD6MXGpnByF7CFYM CVSmEg7UnyEYtaRnyhTdEuJVzmjgVt1kIQglZDQqJ0DAKkFdlj1n14JAXsUHBxRYRsCn +fSbFxEVvhgFBdjyaR3ult61fgKV7DJM4XiUzkmU/X2W2SNl4tck1i65aRCwCTz4VK+y l1T+GgANgcDpJcXs1NJRtwIxxxb/yqy7zzbxk4ZvgPOF2sp96N0dCv1cCnNrgnV85RBo 7Uh5tMFEALOpAGN8+JHr4Jt4OOI85p78fQkxVISLlo65yaky0bVY94W5mFvTFEwXcl5W uEYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=KiP18nVqCHEchA2QZqmRbJnRl4pUchHT5PRsgkgmC+A=; b=IT+4TEm6IeVvPmltOfHxUsItPropeEJqHjkW3iZe9a86XihVUCfYViTb0vd3FwKDmy DWFvbJyYOsvHwufewpHRWLTOreKO9e0fIKO6Q+ZDUbYX4EIetOYGfVISsMatKbAMkQ0q tD9ZCbtUdvKUkxZbE3w+Uufypyty/QiWm89HTk67fjj4TsLoDcX/mnyJ+6HhFOkilQMM 7mmxIDmNwEPcZY/FFLwnb8d+okqqLWovh7IFjjCp3t/fn5gDBFwvjUy13e2NtiSEufz+ puMqmVzsej8snjmrpcp6UW7XeXowKXFQwXIhLuLUnt4fBcCk8fpYapAgvsX0meYrdwsJ Ohpg== X-Gm-Message-State: AG10YOTEgNV430Ex84A4srGOhtNlHHF/JZmtqohsoNDqc/ShXnmr3NJ8owB+MuUReeG1q20foaLq5lBliYRWXdZi MIME-Version: 1.0 X-Received: by 10.129.78.7 with SMTP id c7mr12141688ywb.248.1454867420328; Sun, 07 Feb 2016 09:50:20 -0800 (PST) Received: by 10.129.31.193 with HTTP; Sun, 7 Feb 2016 09:50:20 -0800 (PST) In-Reply-To: <56B64086.4090806@freebsd.org> References: <56B64086.4090806@freebsd.org> Date: Sun, 7 Feb 2016 10:50:20 -0700 Message-ID: Subject: Re: Macbook donation (wireless needs fixing) From: Brandon Vincent To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 17:50:21 -0000 On Sat, Feb 6, 2016 at 11:50 AM, Alfred Perlstein wrote: > So now I have a few macbook laptops, they would be really great to run > FreeBSD except that the wifi isn't supported. https://www.freebsd.org/cgi/man.cgi?query=bwi From owner-freebsd-hackers@freebsd.org Sun Feb 7 21:41:57 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDA25AA1388 for ; Sun, 7 Feb 2016 21:41:57 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C37881A4B for ; Sun, 7 Feb 2016 21:41:57 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8001:cee1:b19e:76f8:e09a:6ad4]) by elvis.mu.org (Postfix) with ESMTPSA id 2EB14345A965; Sun, 7 Feb 2016 13:41:51 -0800 (PST) Subject: Re: Macbook donation (wireless needs fixing) To: Brandon Vincent , FreeBSD Hackers References: <56B64086.4090806@freebsd.org> From: Alfred Perlstein Organization: FreeBSD Message-ID: <56B7BA1E.2020407@freebsd.org> Date: Sun, 7 Feb 2016 13:41:50 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 21:41:57 -0000 On 2/7/16 9:50 AM, Brandon Vincent wrote: > On Sat, Feb 6, 2016 at 11:50 AM, Alfred Perlstein wrote: >> So now I have a few macbook laptops, they would be really great to run >> FreeBSD except that the wifi isn't supported. > https://www.freebsd.org/cgi/man.cgi?query=bwi Oh, strange, let me see why my macbook4,1 doesn't work with this... maybe it's just not loaded by default? -Alfred From owner-freebsd-hackers@freebsd.org Mon Feb 8 00:24:19 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 344A8AA1C47 for ; Mon, 8 Feb 2016 00:24:19 +0000 (UTC) (envelope-from bmvince1@asu.edu) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2D47338 for ; Mon, 8 Feb 2016 00:24:18 +0000 (UTC) (envelope-from bmvince1@asu.edu) Received: by mail-yw0-x22b.google.com with SMTP id u200so13076486ywf.0 for ; Sun, 07 Feb 2016 16:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zg+ivGD4ENuDRIbKTIt45lp6L69W8po85L6hmn3vRyU=; b=lSJRgXC4CoFziwjG7khtjCFrefcMLYoz+CH5SFMCzeq+sZ6aVz/fEVJGyx/crxUG6P xjjW7EO7FeLCBPpR7nRoDYKbLFGrghcrinQ7txeBgBL9seKIKWHtMWeslDvlFA5HsM9F KWwIngfiuwPewlMZvCwKrjG3LYfxpmO6dj1sWn5m4+PUwGKAaZYtW8qkTER5Yb7jLOD2 bXk415uDMQAP/Vfo4wwlXl/E3Q0Y5bgoj0ve23ZI5hNtXgmnz8mI9haySNGjuOVbNRBC bthmjPeSD3Cj+mH0JN9zgCF0zogu9p4KZVrKupUS+VJwf28kIhEKXqYbOjMYjM/7NQim M65g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zg+ivGD4ENuDRIbKTIt45lp6L69W8po85L6hmn3vRyU=; b=YwpksIjTYj7qKt2AjryzKq7Wqn1gZ1+i8V3zD/TiXDFH+AXUeCD08sArihtGCJ/75p OUQrlbi/u/GZ8OgXBqj9rcng4cvZzVW7AUd8OL/sNUgHl8LBCR7kBREXyKjQxFpcsami BedWR0KqGCpU2RuNWUr+pyDMUCwa391uT63B3IORkRYegfDVBqYLhZwoThc60Dg8tz74 EzIcoZBWozboZtiWa5l1kpHlCQ9U+OYFKt5OVBNXKDs9BLcpzCRdWv5ellOr2H89XC2C 3YLfkp/ShGerEHymTFtLqZCGfDeMpx6IvcSnVHS11yhS5niB34ZvPVy0MmejTSOzjnYl lxaA== X-Gm-Message-State: AG10YORs4E7MJI/7+QPsiRthhdR/+beVZy9RZd9D1yfoPDRMRt0fTB5Clzd6QKKX6+XLCiwePAMu51DI1nEiAunD MIME-Version: 1.0 X-Received: by 10.13.204.77 with SMTP id o74mr12547616ywd.338.1454891057760; Sun, 07 Feb 2016 16:24:17 -0800 (PST) Received: by 10.129.31.193 with HTTP; Sun, 7 Feb 2016 16:24:17 -0800 (PST) In-Reply-To: <56B7BA1E.2020407@freebsd.org> References: <56B64086.4090806@freebsd.org> <56B7BA1E.2020407@freebsd.org> Date: Sun, 7 Feb 2016 17:24:17 -0700 Message-ID: Subject: Re: Macbook donation (wireless needs fixing) From: Brandon Vincent To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 00:24:19 -0000 On Sun, Feb 7, 2016 at 2:41 PM, Alfred Perlstein wrote: > Oh, strange, let me see why my macbook4,1 doesn't work with this... maybe > it's just not loaded by default? You'll need the firmware contained in ports/net/bwi-firmware-kmod. From owner-freebsd-hackers@freebsd.org Mon Feb 8 05:40:01 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFDB9A9FF31 for ; Mon, 8 Feb 2016 05:40:01 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A414F1EF for ; Mon, 8 Feb 2016 05:40:01 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8001:cee1:584c:119b:5d5e:73cd]) by elvis.mu.org (Postfix) with ESMTPSA id 72BD2345A92E for ; Sun, 7 Feb 2016 21:40:00 -0800 (PST) Subject: Re: Macbook donation (wireless needs fixing) To: freebsd-hackers@freebsd.org References: <56B64086.4090806@freebsd.org> <56B7BA1E.2020407@freebsd.org> From: Alfred Perlstein Organization: FreeBSD Message-ID: <56B82A2F.7050009@freebsd.org> Date: Sun, 7 Feb 2016 21:39:59 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 05:40:01 -0000 On 2/7/16 4:24 PM, Brandon Vincent wrote: > On Sun, Feb 7, 2016 at 2:41 PM, Alfred Perlstein wrote: >> Oh, strange, let me see why my macbook4,1 doesn't work with this... maybe >> it's just not loaded by default? > You'll need the firmware contained in ports/net/bwi-firmware-kmod. This can't be part of the base distribution? -Alfred From owner-freebsd-hackers@freebsd.org Mon Feb 8 07:14:40 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1B48A9F695 for ; Mon, 8 Feb 2016 07:14:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 C40B87AD; Mon, 8 Feb 2016 07:14:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pa0-x235.google.com with SMTP id yy13so69306049pab.3; Sun, 07 Feb 2016 23:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zy0dYanXlKXfwF1A2Xa5NJrNb058mpx0pPHMGzr76Bs=; b=uXeq7tp7gmXmEstvsmohxZFGxy+SuNYW9porIpjA0iueWuNHQdGs7IYQWyS6Blt7Aq MFZSvV0NZgSsiDaLg5UIMDvlJQjELd6i3KpQHIOmRohr7VtAWvyYPeydLrVfKrHNwsa7 Wh3rGbrth7qPWENTmPFYKZDK9ytWtz9pObxXDMyCIM1gbzu1FN8G6Zyn248SGY3x0//P VoJb5gXDGqfsQqa+YBi6briYA1wrku90BLRNEpwW/RzkXkOsVOgpJbgxlsgYlI3wuMLg dsMZcAYqa5Xxby1SBH1w3waxeYSsOqjIQLIGdYHi4tvj0v6BKQIvjVVBpk4p5CsIAhit QBEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Zy0dYanXlKXfwF1A2Xa5NJrNb058mpx0pPHMGzr76Bs=; b=HJfn+G14+AhJnmjiW8Irr3D13ecFhZ33poXOd428SYClBIuztw4s8gf0W5Yhx4By1G xP/IskC+MNvY6DwRwAHdFp8nP13x2yQUodDq1R/knK/sKYofhzpvlx9AmxhT2a2SODS+ I21/fdYBTCP30UtkTbh2nia6WvirCYk+1yBWO3kv4/21uYM16YgHZMmfh6aGP6aO3iKJ yuE1rbXE1f/F+ejAVSpE2fdrqzBSFz0oRGvLSMctDdKuVm7rD8Ei2lSSeBxZrs/l1nOI Oh6UkDeVDbG8SQlComYX/fbkRe1eFPeShlgJyH4lCyu8ROvHYAEmgQgPms2jHSV0xMQD j7sA== X-Gm-Message-State: AG10YOSG6u+CLH926j2ykk1Ak/X+h3ZjXc/6XeeucfH+Yu7QOCgEe1Wat6nUAyv7Bl9yzA== X-Received: by 10.66.218.225 with SMTP id pj1mr39326213pac.40.1454915680337; Sun, 07 Feb 2016 23:14:40 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:6994:c0e:f554:c8ae? ([2601:601:800:126d:6994:c0e:f554:c8ae]) by smtp.gmail.com with ESMTPSA id a21sm40777331pfj.40.2016.02.07.23.14.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Feb 2016 23:14:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Macbook donation (wireless needs fixing) From: NGie Cooper In-Reply-To: <56B82A2F.7050009@freebsd.org> Date: Sun, 7 Feb 2016 23:14:37 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B64086.4090806@freebsd.org> <56B7BA1E.2020407@freebsd.org> <56B82A2F.7050009@freebsd.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 07:14:41 -0000 > On Feb 7, 2016, at 21:39, Alfred Perlstein wrote: >=20 > On 2/7/16 4:24 PM, Brandon Vincent wrote: >> On Sun, Feb 7, 2016 at 2:41 PM, Alfred Perlstein = wrote: >>> Oh, strange, let me see why my macbook4,1 doesn't work with this... = maybe >>> it's just not loaded by default? >> You'll need the firmware contained in ports/net/bwi-firmware-kmod. > This can't be part of the base distribution? Not sure of the details, but it looks like no: NO_PACKAGE=3D this is a modified version of a restricted firmware :(=E2=80=A6 -Ngie= From owner-freebsd-hackers@freebsd.org Mon Feb 8 08:00:39 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1E73AA0EB5 for ; Mon, 8 Feb 2016 08:00:39 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B49351B1C for ; Mon, 8 Feb 2016 08:00:39 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8001:cee1:8d8c:acfd:b4fe:750c]) by elvis.mu.org (Postfix) with ESMTPSA id 71A07345A965 for ; Mon, 8 Feb 2016 00:00:37 -0800 (PST) Subject: Re: Macbook donation (wireless needs fixing) To: freebsd-hackers@freebsd.org References: <56B64086.4090806@freebsd.org> <56B7BA1E.2020407@freebsd.org> <56B82A2F.7050009@freebsd.org> From: Alfred Perlstein Message-ID: <56B84B22.1030707@mu.org> Date: Mon, 8 Feb 2016 00:00:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 08:00:39 -0000 On 2/7/16 11:14 PM, NGie Cooper wrote: >> On Feb 7, 2016, at 21:39, Alfred Perlstein wrote: >> >> On 2/7/16 4:24 PM, Brandon Vincent wrote: >>> On Sun, Feb 7, 2016 at 2:41 PM, Alfred Perlstein wrote: >>>> Oh, strange, let me see why my macbook4,1 doesn't work with this... maybe >>>> it's just not loaded by default? >>> You'll need the firmware contained in ports/net/bwi-firmware-kmod. >> This can't be part of the base distribution? > Not sure of the details, but it looks like no: > > NO_PACKAGE= this is a modified version of a restricted firmware > > :(… Yes, but last time it was someone being overly zealous about some other firmware that turned out to be fine. Why is this firmware restricted? How are others distributing it? Seems silly. -Alfred From owner-freebsd-hackers@freebsd.org Mon Feb 8 08:10:14 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9882AA12A5 for ; Mon, 8 Feb 2016 08:10:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 89BEE1EF9 for ; Mon, 8 Feb 2016 08:10:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pa0-x231.google.com with SMTP id yy13so69996947pab.3 for ; Mon, 08 Feb 2016 00:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zwmtXyGWJKcfNVn4XJhLRazUtRrkTeCRgtTLD4yd2Ik=; b=zeX9iwL7FVwC9DGnJR7R343ehLgQTXTejtDXQTyEjSbzrw7KSTRWClG5yGQze9TUpn ZtWzZvBjQMhB2qcHbEVVaJP0lSiZIxYvN2+uXwD5fnpJIgSrjfqa4vBpAO9cJbij7Bi4 qHl2w3iCkCdZ5Ps8ew8J3JBJkRAP/c3RjC11a8kTGECvYABv/4N+ReN9tEI9dnRLqnwu PE2Tgq40CvO+cJKxgDb0boWe95p0oOqVi/jO0lFl1nqW4j0c5JdBCMGGuUIAM3399oX2 ZhsA819x6JqkmvIRBOC4A5gJx16UBCHwb1AktT+A9vZfjjv6ZKAOYW4cEGzfHkTTQNV9 Z9UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zwmtXyGWJKcfNVn4XJhLRazUtRrkTeCRgtTLD4yd2Ik=; b=LbeNQTDTGvcX3VGkh1uI7UHbCWHaE6/I06yYcVw93GalNVZxTSmov5FMxZWfeawW4Y +e9uw3yy+oX+hsU7WCUrb+Q+iMgLWDgUlGdjQennb8LprF5C2FuylCPkCMIYJECdq+VL DvEaVB/icLY+pOX1+XAPS9Vaa8zr/nHxbEfp6j2nIgKBqo0DXXY8uJCMacJJXTzpphC3 V1hB0Q5DoVF4t/mZSxDzidxArWgXgkzD5CPg9o58ZORvmyXSK2VQZiw5IPOCiIBy5PTj c/e9cobDgcM0nYnLO06LonVSXfgoG1dJxqEcoDPDZgIBvDbD5PylAgvXH8ANldWqIeCm Nm4Q== X-Gm-Message-State: AG10YORNnHt5f2jGi7M9LMQSrAVfwkewQJT/5v5CxXqtyM3LEy3O65e60TeosfDGzlKDpQ== X-Received: by 10.66.129.232 with SMTP id nz8mr40518619pab.102.1454919014107; Mon, 08 Feb 2016 00:10:14 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:6994:c0e:f554:c8ae? ([2601:601:800:126d:6994:c0e:f554:c8ae]) by smtp.gmail.com with ESMTPSA id v29sm41236318pfa.31.2016.02.08.00.10.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 00:10:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Macbook donation (wireless needs fixing) From: NGie Cooper In-Reply-To: <56B84B22.1030707@mu.org> Date: Mon, 8 Feb 2016 00:10:11 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <996060A3-0460-4E06-ACDD-D9034CA505D2@gmail.com> References: <56B64086.4090806@freebsd.org> <56B7BA1E.2020407@freebsd.org> <56B82A2F.7050009@freebsd.org> <56B84B22.1030707@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 08:10:14 -0000 > On Feb 8, 2016, at 00:00, Alfred Perlstein wrote: >=20 >=20 >=20 > On 2/7/16 11:14 PM, NGie Cooper wrote: >>> On Feb 7, 2016, at 21:39, Alfred Perlstein = wrote: >>>=20 >>> On 2/7/16 4:24 PM, Brandon Vincent wrote: >>>> On Sun, Feb 7, 2016 at 2:41 PM, Alfred Perlstein = wrote: >>>>> Oh, strange, let me see why my macbook4,1 doesn't work with = this... maybe >>>>> it's just not loaded by default? >>>> You'll need the firmware contained in ports/net/bwi-firmware-kmod. >>> This can't be part of the base distribution? >> Not sure of the details, but it looks like no: >>=20 >> NO_PACKAGE=3D this is a modified version of a restricted firmware >>=20 >> :(=E2=80=A6 > Yes, but last time it was someone being overly zealous about some = other firmware that turned out to be fine. >=20 > Why is this firmware restricted? How are others distributing it? = Seems silly. OpenWRT seems to encourage dumping of wireless firmware [1], and then = modifies before they distribute them (I=E2=80=99m guessing based on the = NO_PACKAGE message above)? I could be wrong, but this seems to open a = number of doors (legally) that would be a bad idea to open without a = huge disclaimer because of export laws, copyright laws, etc.. It would be a better idea to couple this with FreeBSD if OpenWRT reverse = engineered the firmware (legally) and released the source code for their = derivative. Based on what I=E2=80=99m reading (as always, my favorite = acronym =E2=80=94 IANAL), this seems like a really nasty legal mess for = the project to get in to. Thanks! -Ngie= From owner-freebsd-hackers@freebsd.org Mon Feb 8 09:09:20 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14AE5A9E300 for ; Mon, 8 Feb 2016 09:09:20 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp3.mail.clearhost.co.uk (smtp3.mail.clearhost.co.uk [IPv6:2001:1420::25:103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.mail.clearhost.co.uk", Issuer "RapidSSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B68F01A06 for ; Mon, 8 Feb 2016 09:09:19 +0000 (UTC) (envelope-from prt@prt.org) Received: from [2001:1420:a:105:c62c:3ff:fe2f:bf] (port=49395 helo=parsnip.heronsbrook.org.uk) by smtp3.mail.clearhost.co.uk with esmtpa (Exim 4.76 (FreeBSD)) (envelope-from ) id 1aShoq-0007ik-Uk for freebsd-hackers@freebsd.org; Mon, 08 Feb 2016 09:09:16 +0000 To: "freebsd-hackers@freebsd.org" From: Paul Thornton Subject: Troubleshooting panic on 10.2-RELEASE Message-ID: <56B85B7E.9080705@prt.org> Date: Mon, 8 Feb 2016 09:10:22 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 09:09:20 -0000 Hi My Kernel debugging isn't up to troubleshooting what's going on here. We have two out of 10 identical VMs that regularly (between 5 and 20 hours) panic. On one, I have recompiled GENERIC to get a kernel.debug and have crash dumps being recorded. They are running GENERIC kernels with ZFS-on-root (dmesg at the bottom of this mail). All of the other machines work fine, although the ones that are crashing have the highest use at the moment. The panic is lock-related, and going by pid 12 ([intr]) is interrupt related to network tx/rx. Unread portion of the kernel message buffer: Sleeping thread (tid 100024, pid 12) owns a non-sleepable lock KDB: stack backtrace of thread 100024: #0 0xffffffff80952061 at mi_switch+0xe1 #1 0xffffffff8099043a at sleepq_wait+0x3a #2 0xffffffff80951a87 at _sleep+0x287 #3 0xffffffff80a040c4 at filt_bpfread+0x94 #4 0xffffffff809079eb at knote+0xdb #5 0xffffffff80a00acb at catchpacket+0x67b #6 0xffffffff80a00d20 at bpf_mtap+0x1e0 #7 0xffffffff80a0f634 at ether_nh_input+0x174 #8 0xffffffff80a177d2 at netisr_dispatch_src+0x62 #9 0xffffffff80df8fcf at vmxnet3_rxq_eof+0x4ff #10 0xffffffff80df86f1 at vmxnet3_legacy_intr+0xe1 #11 0xffffffff8091482b at intr_event_execute_handlers+0xab #12 0xffffffff80914c76 at ithread_loop+0x96 #13 0xffffffff8091244a at fork_exit+0x9a #14 0xffffffff80d30cde at fork_trampoline+0xe panic: sleeping thread cpuid = 0 So far, out of 5 dumps, I see two patterns emerging. One, like the above, involves vmxnet3, the other (to my untrained eye) looks like a write on a Unix socket. They both share knote. (kgdb) backtrace #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff80948642 in kern_reboot (howto=260) at ../../../kern/kern_shutdown.c:451 #2 0xffffffff80948a25 in vpanic (fmt=, ap=) at ../../../kern/kern_shutdown.c:758 #3 0xffffffff809488b3 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:687 #4 0xffffffff80995f89 in propagate_priority (td=) at ../../../kern/subr_turnstile.c:227 #5 0xffffffff80996a0e in turnstile_wait (ts=, owner=, queue=) at ../../../kern/subr_turnstile.c:743 #6 0xffffffff8092ea3b in __mtx_lock_sleep (c=0xfffff80027b63718, tid=18446735277657056416, opts=, file=, line=0) at ../../../kern/kern_mutex.c:522 #7 0xffffffff809079a5 in knote (list=0xfffff80027ca50a8, hint=0, lockflags=) at ../../../kern/kern_event.c:1873 #8 0xffffffff80a00acb in catchpacket (d=, pkt=, pktlen=, snaplen=, cpfn=, bt=) at ../../../net/bpf.c:980 #9 0xffffffff80a00d20 in bpf_mtap (bp=0xfffff800027e3680, m=0xfffff800274d2b00) at ../../../net/bpf.c:2142 #10 0xffffffff80a0f634 in ether_nh_input (m=) at ../../../net/if_ethersubr.c:520 #11 0xffffffff80a177d2 in netisr_dispatch_src (proto=, source=, m=0x0) at ../../../net/netisr.c:976 #12 0xffffffff80df8fcf in vmxnet3_rxq_eof (rxq=0xfffff80002797400) at ../../../dev/vmware/vmxnet3/if_vmx.c:2076 #13 0xffffffff80df86f1 in vmxnet3_legacy_intr (xsc=0xfffff800027c3800) at ../../../dev/vmware/vmxnet3/if_vmx.c:2245 #14 0xffffffff8091482b in intr_event_execute_handlers (p=, ie=0xfffff800027ea100) at ../../../kern/kern_intr.c:1264 #15 0xffffffff80914c76 in ithread_loop (arg=0xfffff800027ca7a0) at ../../../kern/kern_intr.c:1277 #16 0xffffffff8091244a in fork_exit (callout=0xffffffff80914be0 , arg=0xfffff800027ca7a0, frame=0xfffffe00934ccac0) at ../../../kern/kern_fork.c:1018 #17 0xffffffff80d30cde in fork_trampoline () at ../../../amd64/amd64/exception.S:611 #18 0x0000000000000000 in ?? () [From a different panic and reboot] (kgdb) backtrace #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff80948642 in kern_reboot (howto=260) at ../../../kern/kern_shutdown.c:451 #2 0xffffffff80948a25 in vpanic (fmt=, ap=) at ../../../kern/kern_shutdown.c:758 #3 0xffffffff809488b3 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:687 #4 0xffffffff80995f89 in propagate_priority (td=) at ../../../kern/subr_turnstile.c:227 #5 0xffffffff80996a0e in turnstile_wait (ts=, owner=, queue=) at ../../../kern/subr_turnstile.c:743 #6 0xffffffff8092ea3b in __mtx_lock_sleep (c=0xfffff8002770de18, tid=18446735278278059168, opts=, file=, line=0) at ../../../kern/kern_mutex.c:522 #7 0xffffffff809079a5 in knote (list=0xfffff80027866b80, hint=0, lockflags=) at ../../../kern/kern_event.c:1873 #8 0xffffffff809bcc35 in sowakeup (so=0xfffff80027866ae0, sb=0xfffff80027866b70) at ../../../kern/uipc_sockbuf.c:189 #9 0xffffffff809cce46 in uipc_send (so=0xfffff8002786fae0, flags=, m=, nam=0x0, control=0x0, td=) at ../../../kern/uipc_usrreq.c:902 #10 0xffffffff809c0526 in sosend_generic (so=0xfffff8002786fae0, addr=0x0, uio=0xfffffe00935fa960, top=, control=, flags=, td=0x0) at ../../../kern/uipc_socket.c:1283 #11 0xffffffff809a4869 in soo_write (fp=, uio=0xfffffe00935fa960, active_cred=, flags=, td=) at ../../../kern/sys_socket.c:103 #12 0xffffffff8099c647 in dofilewrite (td=0xfffff800276e24a0, fd=7, fp=0xfffff80027871d20, auio=0xfffffe00935fa960, offset=, flags=0) at file.h:304 #13 0xffffffff8099c378 in kern_writev (td=0xfffff800276e24a0, fd=7, auio=0xfffffe00935fa960) at ../../../kern/sys_generic.c:481 #14 0xffffffff8099c303 in sys_write (td=, uap=) at ../../../kern/sys_generic.c:396 #15 0xffffffff80d4b3a7 in amd64_syscall (td=0xfffff800276e24a0, traced=0) at subr_syscall.c:134 #16 0xffffffff80d30a8b in Xfast_syscall () at ../../../amd64/amd64/exception.S:396 #17 0x0000000801a1cc0a in ?? () We haven't seen this on any other 10.2-RELEASE install - either on a VM or physical machine. What's the best way forward to troubleshoot this? Thanks Paul. boot dmesg follows: Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.2-RELEASE-p8 #1: Fri Feb 5 16:22:56 UTC 2016 root@portal.dev:/usr/src/sys/amd64/compile/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz (3500.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 Features=0xfa3fbff Features2=0xfdfa3203 AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x272a XSAVE Features=0x1 TSC: P-state invariant Hypervisor: Origin = "VMwareVMware" real memory = 2147483648 (2048 MB) avail memory = 2050248704 (1955 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 950 cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1060-0x106f at device 7.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 7.3 (no driver attached) vgapci0: port 0x1070-0x107f mem 0xe8000000-0xefffffff,0xfe000000-0xfe7fffff irq 16 at device 15.0 on pci0 vgapci0: Boot video device pcib2: at device 17.0 on pci0 pci2: on pcib2 pcib3: at device 21.0 on pci0 pci3: on pcib3 vmx0: port 0x4000-0x400f mem 0xfd5fc000-0xfd5fcfff,0xfd5fd000-0xfd5fdfff,0xfd5fe000-0xfd5fffff irq 18 at device 0.0 on pci3 vmx0: Ethernet address: 00:0c:29:e5:ef:c4 pcib4: at device 21.1 on pci0 pci4: on pcib4 pcib5: at device 21.2 on pci0 pci5: on pcib5 pcib6: at device 21.3 on pci0 pci6: on pcib6 pcib7: at device 21.4 on pci0 pci7: on pcib7 pcib8: at device 21.5 on pci0 pci8: on pcib8 pcib9: at device 21.6 on pci0 pci9: on pcib9 pcib10: at device 21.7 on pci0 pci10: on pcib10 pcib11: at device 22.0 on pci0 pci11: on pcib11 vmx1: port 0x5000-0x500f mem 0xfd4fc000-0xfd4fcfff,0xfd4fd000-0xfd4fdfff,0xfd4fe000-0xfd4fffff irq 19 at device 0.0 on pci11 vmx1: Ethernet address: 0a:d1:c0:01:03:c0 pcib12: at device 22.1 on pci0 pci12: on pcib12 pcib13: at device 22.2 on pci0 pci13: on pcib13 pcib14: at device 22.3 on pci0 pci14: on pcib14 pcib15: at device 22.4 on pci0 pci15: on pcib15 pcib16: at device 22.5 on pci0 pci16: on pcib16 pcib17: at device 22.6 on pci0 pci17: on pcib17 pcib18: at device 22.7 on pci0 pci18: on pcib18 pcib19: at device 23.0 on pci0 pci19: on pcib19 mpt0: port 0x6000-0x60ff mem 0xfd3ec000-0xfd3effff,0xfd3f0000-0xfd3fffff irq 16 at device 0.0 on pci19 mpt0: MPI Version=1.5.0.0 pcib20: at device 23.1 on pci0 pci20: on pcib20 pcib21: at device 23.2 on pci0 pci21: on pcib21 pcib22: at device 23.3 on pci0 pci22: on pcib22 pcib23: at device 23.4 on pci0 pci23: on pcib23 pcib24: at device 23.5 on pci0 pci24: on pcib24 pcib25: at device 23.6 on pci0 pci25: on pcib25 pcib26: at device 23.7 on pci0 pci26: on pcib26 pcib27: at device 24.0 on pci0 pci27: on pcib27 vmx2: port 0x7000-0x700f mem 0xfd2fc000-0xfd2fcfff,0xfd2fd000-0xfd2fdfff,0xfd2fe000-0xfd2fffff irq 17 at device 0.0 on pci27 vmx2: Ethernet address: 00:0c:29:e5:ef:d8 pcib28: at device 24.1 on pci0 pci28: on pcib28 pcib29: at device 24.2 on pci0 pci29: on pcib29 pcib30: at device 24.3 on pci0 pci30: on pcib30 pcib31: at device 24.4 on pci0 pci31: on pcib31 pcib32: at device 24.5 on pci0 pci32: on pcib32 pcib33: at device 24.6 on pci0 pci33: on pcib33 pcib34: at device 24.7 on pci0 pci34: on pcib34 acpi_acad0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcbfff,0xcc000-0xccfff,0xdc000-0xdffff,0xe0000-0xe7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range acpi_throttle0: on cpu0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled random: unblocking device. da0 at mpt0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 40960MB (83886080 512 byte sectors: 255H 63S/T 5221C) da0: quirks=0x40 Timecounter "TSC-low" frequency 1749998500 Hz quality 1000 Trying to mount root from ufs:/dev/da0p3 [rw]... WARNING: / was not properly dismounted ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) From owner-freebsd-hackers@freebsd.org Tue Feb 9 17:54:57 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2F5EAA2E0D; Tue, 9 Feb 2016 17:54:57 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 B2703DBF; Tue, 9 Feb 2016 17:54:57 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3q0Bgy5fHQz13c; Tue, 9 Feb 2016 18:54:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:organization:subject:subject:from:from :date:date:content-transfer-encoding:content-type:content-type :mime-version:received:received:received:received; s=jakla4; t= 1455040491; x=1457632492; bh=382RecCx/1Qh0yulE0Jaa2xipwiy5kAHQ24 qARe20GE=; b=TJi+3QRJxQAuOLDJvFQZ+US6qI6LjIet3+g4Fnz9iMkAMpqWktU R4J/0Zy10ghMVM/x2zPraq0iETvx4dph0jWu6gvadDStYaJl9NgzK80Sdt9TRgRh x6M+L+I8IJ+x78sV8ZQDuF0UmtYO9xBaAEVN0WB90+CFL0fP9EWfNK5w= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id tzonGcK5m8BJ; Tue, 9 Feb 2016 18:54:51 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3q0Bgv4XrTz13b; Tue, 9 Feb 2016 18:54:51 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3q0Bgv3gMbznP; Tue, 9 Feb 2016 18:54:51 +0100 (CET) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Tue, 09 Feb 2016 18:54:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 Feb 2016 18:54:51 +0100 From: Mark Martinec To: freebsd-hackers@freebsd.org Cc: freebsd-net@FreeBSD.org, soc-admins@FreeBSD.org Subject: Google Summer of Code 2016, unified ping/ping6, traceroute/traceroute6, ... Organization: Jozef Stefan Institute Message-ID: <3c7c36bc8d7f0bdb4e04466d3d506960@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:54:58 -0000 There is now a timeline published for Google Summer of Code 2016: https://developers.google.com/open-source/gsoc/timeline Will FreeBSD apply for this year's participation in GSoC 2016? I'm not a committer or a mentor, although last year I have submitted two ideas for GSoC projects, for which I still have great interest as a user: https://wiki.freebsd.org/SummerOfCodeIdeas#Task_name.2A:_Unified_ping_and_ping6 https://wiki.freebsd.org/SummerOfCodeIdeas#Task_name.2A:_Unified_traceroute_and_traceroute6 Last year there were two or three seemingly highly qualified and motivated candidates for these two tasks. This year I have just received a query from a new interested candidate. Unfortunately, despite posting to freebsd-hackers ML and possibly elsewhere, last year these candidates did not receive any reply (apart from mine, suggesting contacts and indicated on a Wiki page). So the problem is finding a mentor that is willing to accept the task of mentoring these two projects. I'm willing to participate with comments, review and technical suggestions, but someone (or preferably two persons) familiar with FreeBSD coding styles and practices is needed, and to fill the GSoC role of a mentor. Finding an interested qualified mentor is also probably a pre-requisite that a student's work won't be in vain and get a chance of being adopted in a FreeBSD project. I'm willing to elaborate more on my two proposed projects, as the submission form (links above) had a word count limit on a project description and on justifying a need. Is there a better mailing list that freebsd-hackers@ to cover GSoC topics? Mark From owner-freebsd-hackers@freebsd.org Wed Feb 10 09:16:22 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEE1EAA3E66; Wed, 10 Feb 2016 09:16:22 +0000 (UTC) (envelope-from 8ohit.dua@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 78FDAE21; Wed, 10 Feb 2016 09:16:22 +0000 (UTC) (envelope-from 8ohit.dua@gmail.com) Received: by mail-ig0-x232.google.com with SMTP id ik10so10509488igb.1; Wed, 10 Feb 2016 01:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yCtwQvZ9UAun88g1KOMnjbji+YJn+QTo6V4aO7GctrI=; b=ubi8d8Z9Rf2CIYXtfveRGiHew2nrhwtt3sODHBktaOmgcmAf4vbmEZU9hpkCqXY0/0 qw7jZpCg3yaebDj2hZmUOpdakEslO8ekCErH8O+H6jifIaerk+Jw2YrAWAcdbrJwpN32 Oj5HfHzXLNcF3VoyUTF/rQChAoEvVd50PLLrZcLZf28Gf2egWQuG5YbvDsIC6nlElzin MLhkjo+yrRzBDv+f/D18DlLKvxxtBnbYvKkIj9mp/Cyqe3fH5HD5bVcQ3hyZlHLFmLaw aOMD0WKZabERWAzM5O/k/PrYPwchwTeU8VWHwwn0eiyVeYjWYECyyWfXlC4m1V+iWjCE x11Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yCtwQvZ9UAun88g1KOMnjbji+YJn+QTo6V4aO7GctrI=; b=jmLULPGuO1u7gsN628qaDpCoQ67Wn9W/X41q8NvYVJ0E749D34hO0FrMdyOGlZ6I2F 5XcsJK5SSlGoMahb78adeop+ohJ/8hvVlEYCz/BR+wX93HlELBSpMyeuPw5QImvO1kPy F3DQCKvucFYb4xzrCiF96R3onmKMOKG2PD3sDThysuVZil12AH4sPP4ZA7zaMEAiFKDO xuwEAhdcoAyJB73c4yoFM4cxTjRhr6/BYnP6VtkYjwDZUyO0MPCx+56usL5oo2tzNqmz sNwmJlgEQxPenqb+pXa9JAGxpnPEBdev1Yxu6S6VA2c6tu0NG2Fhh4CGyVWQ6GanH7FU /Lug== X-Gm-Message-State: AG10YOTLX8QqMrEg6fHyqsPqTGJQ9hIENa93GdhxJeeDgKrk1Ejonh/qAxVRSwiSX1zoWl3lGZ5rdsQY/ArYGw== MIME-Version: 1.0 X-Received: by 10.50.137.40 with SMTP id qf8mr6205039igb.61.1455095781827; Wed, 10 Feb 2016 01:16:21 -0800 (PST) Received: by 10.79.27.140 with HTTP; Wed, 10 Feb 2016 01:16:21 -0800 (PST) Received: by 10.79.27.140 with HTTP; Wed, 10 Feb 2016 01:16:21 -0800 (PST) In-Reply-To: <3c7c36bc8d7f0bdb4e04466d3d506960@mailbox.ijs.si> References: <3c7c36bc8d7f0bdb4e04466d3d506960@mailbox.ijs.si> Date: Wed, 10 Feb 2016 14:46:21 +0530 Message-ID: Subject: Re: Google Summer of Code 2016, unified ping/ping6, traceroute/traceroute6, ... From: Rohit Dua <8ohit.dua@gmail.com> To: Mark Martinec Cc: freebsd-net@freebsd.org, soc-admins@freebsd.org, freebsd-hackers@freebsd.org X-Mailman-Approved-At: Wed, 10 Feb 2016 12:06:40 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 09:16:22 -0000 Hi I'm willing to work on this project for GSOC 2016. I'm looking forward to a more elaborate description on these topics. I'm not sure but can't we just use the freebsd-net mailing list for these GSOC project(s) Thanks Rohit Dua On 9 Feb 2016 23:24, "Mark Martinec" wrote: > There is now a timeline published for Google Summer of Code 2016: > https://developers.google.com/open-source/gsoc/timeline > > Will FreeBSD apply for this year's participation in GSoC 2016? > > I'm not a committer or a mentor, although last year I have > submitted two ideas for GSoC projects, for which I still have > great interest as a user: > > > https://wiki.freebsd.org/SummerOfCodeIdeas#Task_name.2A:_Unified_ping_and_ping6 > > https://wiki.freebsd.org/SummerOfCodeIdeas#Task_name.2A:_Unified_traceroute_and_traceroute6 > > Last year there were two or three seemingly highly qualified and > motivated candidates for these two tasks. This year I have just > received a query from a new interested candidate. Unfortunately, > despite posting to freebsd-hackers ML and possibly elsewhere, > last year these candidates did not receive any reply (apart > from mine, suggesting contacts and indicated on a Wiki page). > > So the problem is finding a mentor that is willing to accept > the task of mentoring these two projects. I'm willing to > participate with comments, review and technical suggestions, > but someone (or preferably two persons) familiar with FreeBSD > coding styles and practices is needed, and to fill the > GSoC role of a mentor. Finding an interested qualified mentor > is also probably a pre-requisite that a student's work won't be > in vain and get a chance of being adopted in a FreeBSD project. > > I'm willing to elaborate more on my two proposed projects, > as the submission form (links above) had a word count limit > on a project description and on justifying a need. > > Is there a better mailing list that freebsd-hackers@ to cover > GSoC topics? > > Mark > From owner-freebsd-hackers@freebsd.org Wed Feb 10 11:21:04 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D57E1AA2DC7 for ; Wed, 10 Feb 2016 11:21:04 +0000 (UTC) (envelope-from clomosapup@thrma.com) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id C535FDA8 for ; Wed, 10 Feb 2016 11:21:04 +0000 (UTC) (envelope-from clomosapup@thrma.com) Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 0B6C0206C9BA for ; Wed, 10 Feb 2016 03:08:50 -0800 (PST) Date: Wed, 10 Feb 2016 04:14:42 -0700 (MST) From: clomosapup To: freebsd-hackers@freebsd.org Message-ID: <1455102882934-6075272.post@n5.nabble.com> In-Reply-To: <56B64086.4090806@freebsd.org> References: <56B64086.4090806@freebsd.org> Subject: Re: Macbook donation (wireless needs fixing) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 10 Feb 2016 12:24:24 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 11:21:04 -0000 These would be your "shovel and pick" : 1. FreeBSD Device Drivers: A Guide for the Intrepid 2. Your ordinary specs for Broadcom's bcm43xx chipset 3. Be careful 4. A programmer's time machine 5. Any configurable text editor Be warned, this could turn out to be addictive. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Macbook-donation-wireless-needs-fixing-tp6074326p6075272.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@freebsd.org Thu Feb 11 02:17:39 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE1D9AA1747 for ; Thu, 11 Feb 2016 02:17:38 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DDA9A93 for ; Thu, 11 Feb 2016 02:17:38 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-qk0-x230.google.com with SMTP id x1so14243215qkc.1 for ; Wed, 10 Feb 2016 18:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6xz2XCFYE+6bAQK0zamaWgJaLy41nfCOxflz9voOnRI=; b=L0L5zLcf2XjsGZ4bV3G3hv+Sb0tt3hWO9+17HFOBBXOtnmoov9MfP9Cjbp23e9ZGja BGP4Hx5Lg2eXdxSuUK3zfKZRGAbj6i3ciBRz+1r7qSGigrSbxqQd65KXoq/Tc1SqRooH dPtBJgAMhPooPg/kMHSwrRqDgsI7EIJNCtIeNRUqv8/fBCsKfx+iGSASCEvL4YcMcTG0 bdJ+qa2X16jPsSA68OhBJbPbdk7sRLioCw14xQt6+/Rfj+8Kc+32EG7JYA2QLLzyqlS0 eYy5F2DOitvjAEGsLlEIxtx0CMHWxXE8B4KP6QA+u+Na5liAa5PPT6/O0CH+6TT7DVO8 PbsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6xz2XCFYE+6bAQK0zamaWgJaLy41nfCOxflz9voOnRI=; b=Hl6CYQY2LUiKG++cXE9RAB7A0IXyK1FpPM9Hq6UpH2K9R3ES5gc2PYq5itWuYj+s5w 3eFgcg6FleAMDWOBB9kIa+aL5gD/KgDccLtDAocPpbvw5WwUXowAb5gi9vI7Mg8J3q4W mAxg5eYX0FP2ZhWSwmR77P3xugqNZnw06QU65i/jiofvxQgBiBXPae30HXMPZhV4DCw7 JNiDn77JD8vz9IWJsqEh1+6hbBtMA8n3NPlbQ7xNPG0c0nR4mJIEr8LlMlIxjDSgP6bA Xe9ErVvCALKQgFNGJgNyvfGZ78Gnv9A1+GFvGI3lcymOYqVeOteLGyql0hFsdcAZTyXV 2yIg== X-Gm-Message-State: AG10YOToxbrtPKQM0y89WL6aAb4cNiQCdOvPqWhAxXUwrEPWCrIHbNaEomwvGi5Sbrlj94cHvJFNkmjTIAiHa5t3yfmE8qtQ6GJmur/I80FdsEbvAtTr3HyLYPIK23R7gav4LEZaOAjtQUWkEmSWHl+bfxY= X-Received: by 10.55.41.160 with SMTP id p32mr47742065qkp.69.1455157056884; Wed, 10 Feb 2016 18:17:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.45.71 with HTTP; Wed, 10 Feb 2016 18:17:22 -0800 (PST) In-Reply-To: <5688F015.4090002@bakulin.de> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> From: "Lundberg, Johannes" Date: Wed, 10 Feb 2016 18:17:22 -0800 Message-ID: Subject: Re: MMC/SDIO stack under CAM To: Ilya Bakulin Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Alexander Motin , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 02:17:39 -0000 Hi Ilya This is great! I've got a Tronsmart ARA X5 and just purchased a few UP boards and it would be really nice if I could utilize the onboard eMMC. These are all Intel Cherrytrail platforms. Please let me know if there's anything (testing?) I can do to speed up the process. -- Name: Johannes Lundberg Position: Mirama project leader Phone: +1-408-636-2161 Skype: brilliantjohannes Online: LinkedIn Facebook Reddit Twitter GitHub GitLab Company: Mirama Brilliantservice US Brilliantservice JP On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin wrote: > So, more than one year has passed, and I'd like to resurrect this work > and move forward. > > I have uploaded a new diff and created a completely new revision to > track the development: https://reviews.freebsd.org/D4761 > > What it is able to do now: > > * Read/write on SD/SDHC/MMC cards! > * Detect SDIO cards and create devices that correspond to SDIO functions > > This all works only on BeagleBone currently, because some changes need > to be done in each SDHCI-compliant driver to make it interact with CAM. > I have purchased a Wandboard Quad that has an integrated SDIO WiFi chip, > so I hope to tweak its SDHCI driver as well. > > I haven't profiled the stack because: > * Now we have only SD/MMC cards that are slow anyway; > * I don't know how to do it in FreeBSD :-) > > Please review this diff and tell what you think! > > On 01/03/14 18:05, Adrian Chadd wrote: > > On 1 March 2014 08:46, Ilya Bakulin wrote: > >> Hi Adrian, > >> > >> On 24.02.14, 16:59, Adrian Chadd wrote: > >>> hi, > >>> > >>> Let me just reiterate some .. well, experience doing this stuff at QC= A. > >>> > >>> You really, absolutely don't want too much overhead in the MMC/SDIO > >>> path between whatever is issuing things and the network driver. > >>> > >>> There was significant performance work done at QCA on a local MMC/SDI= O > >>> driver and bus to get extremely low latency and CPU utilisation when > >>> pushing around small transactions. The current CAM locking model is > >>> not geared towards getting to high transaction rates. > >> So here you mean some work done on Linux MMC/SDIO stack by QCA > >> which made it far better than current Linux MMC stack in terms of > >> high SDIO I/O rates? > > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at small > > transactions to sustain the wifi speeds customers required. > > > >>> You may think this is a very architecturally pretty solution and it > >>> indeed may be. But if it doesn't perform as well as the existing loca= l > >>> hacks that vendors have done, no company deploying this hardware is > >>> going to want to use it. They'll end up realising there's this massiv= e > >>> CAM storage layer in between and either have to sit down to rip it up > >>> and replace it with something lightweight, or they'll say "screw it" > >>> and go back to the vendor supplied hacked up Linux solution. > >> I think that if the "architecturally pretty solution" behaves worse th= an > >> some ugly hacks, then it may be not so pretty or the architecture is > >> just broken > >> by design. > >> > >>> So I highly recommend you profile things - and profile things with > >>> lots of small transactions. If the CAM overhead is more than a tiny, > >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. :-) > >> I don't really know what to compare with. For MMC/SD cards it is prett= y > >> obvious, but then these cards will be likely the bottleneck, not the > stack. > >> And the only goal would be to not make the stack slower than it is now= . > >> But, as ATA devices are much faster than MMC/SD, I don't think this wi= ll > >> be a problem. > >> > >> For SDIO things are different. But we don't have any drivers (yet), > except > >> mv_sdiowl that I'm writing, to test on. So I have to bring the SDIO > >> stack on CAM, > >> than bring mv_sdiowl to the state when it can actually transmit the > >> data, and then > >> compare performance with the vendor-supplied Linux driver. > >> We'll see then if there is a room for improvement... > > That sounds like a plan. > > > > Just note that although storage looks like it's doing much more > > throughput, the IO size also matters. As I said above, it's not > > uncommon to have > 1000 receive frames a second on 802.11n; and that > > can peak much higher than that. That's not the kind of IO rate you see > > on SD cards. :-) > > > > > > > > -a > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > > > -- > Regards, > Ilya Bakulin > > > --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-hackers@freebsd.org Thu Feb 11 18:43:15 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0357EAA6210; Thu, 11 Feb 2016 18:43:15 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6513794B; Thu, 11 Feb 2016 18:43:13 +0000 (UTC) (envelope-from ilya@bakulin.de) DKIM-Filter: OpenDKIM Filter v2.10.3 olymp.kibab.com 405134E679 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1455216191; bh=XZ4eNKXf4QhM5JSmcSdX3bTOAM/fCSgWxsTz8dzeGGI=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=lsiNR3Hpc5M0n7LWFYnQPbhUyD01yXMgGUz2VffBdio7JCjmnUqAGvQ8jLMPT+6+n sD7FDJd2SKHfeBWYzPX1rvgRuB94355qNcy8cYYYUXe0z1wuMJj4LNOKlmYTbZynpl 2uJEgLutMK0zBFHIEx/DBS1TIgFy1vW4PIlbLGj0= In-Reply-To: References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> MIME-Version: 1.0 Subject: Re: MMC/SDIO stack under CAM From: Ilya Bakulin Date: Thu, 11 Feb 2016 19:42:57 +0100 To: "Lundberg, Johannes" CC: "freebsd-hackers@freebsd.org" , Adrian Chadd , Alexander Motin , "freebsd-arm@freebsd.org" Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 18:43:15 -0000 Hi Johannes, My work doesn't include writing drivers for SDHCI controllers. But if the controller on your new boards is supported by FreeBSD, then you can really test the new stack! Especially if the controller driver for your board is based on dev/sdhci, adapting it to work with the new stack is trivial. For example, iMX6 SDHCI needed only a couple of lines: https://github.com/kibab/freebsd/commit/df6d8d534740aa3633979da0a9d0ca00b60db0e9 Please let me know when you get the new boards and we will figure out what we need. On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" wrote: >Hi Ilya > >This is great! > >I've got a Tronsmart ARA X5 and just purchased a few UP > >boards >and it would be really nice if I could utilize the onboard eMMC. These >are >all Intel Cherrytrail platforms. > >Please let me know if there's anything (testing?) I can do to speed up >the >process. > > > >-- >Name: Johannes Lundberg >Position: Mirama project leader >Phone: +1-408-636-2161 >Skype: brilliantjohannes >Online: LinkedIn >Facebook > Reddit > Twitter > GitHub > >GitLab >Company: Mirama Brilliantservice US > Brilliantservice JP > > >On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin wrote: > >> So, more than one year has passed, and I'd like to resurrect this >work >> and move forward. >> >> I have uploaded a new diff and created a completely new revision to >> track the development: https://reviews.freebsd.org/D4761 >> >> What it is able to do now: >> >> * Read/write on SD/SDHC/MMC cards! >> * Detect SDIO cards and create devices that correspond to SDIO >functions >> >> This all works only on BeagleBone currently, because some changes >need >> to be done in each SDHCI-compliant driver to make it interact with >CAM. >> I have purchased a Wandboard Quad that has an integrated SDIO WiFi >chip, >> so I hope to tweak its SDHCI driver as well. >> >> I haven't profiled the stack because: >> * Now we have only SD/MMC cards that are slow anyway; >> * I don't know how to do it in FreeBSD :-) >> >> Please review this diff and tell what you think! >> >> On 01/03/14 18:05, Adrian Chadd wrote: >> > On 1 March 2014 08:46, Ilya Bakulin wrote: >> >> Hi Adrian, >> >> >> >> On 24.02.14, 16:59, Adrian Chadd wrote: >> >>> hi, >> >>> >> >>> Let me just reiterate some .. well, experience doing this stuff >at QCA. >> >>> >> >>> You really, absolutely don't want too much overhead in the >MMC/SDIO >> >>> path between whatever is issuing things and the network driver. >> >>> >> >>> There was significant performance work done at QCA on a local >MMC/SDIO >> >>> driver and bus to get extremely low latency and CPU utilisation >when >> >>> pushing around small transactions. The current CAM locking model >is >> >>> not geared towards getting to high transaction rates. >> >> So here you mean some work done on Linux MMC/SDIO stack by QCA >> >> which made it far better than current Linux MMC stack in terms of >> >> high SDIO I/O rates? >> > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at >small >> > transactions to sustain the wifi speeds customers required. >> > >> >>> You may think this is a very architecturally pretty solution and >it >> >>> indeed may be. But if it doesn't perform as well as the existing >local >> >>> hacks that vendors have done, no company deploying this hardware >is >> >>> going to want to use it. They'll end up realising there's this >massive >> >>> CAM storage layer in between and either have to sit down to rip >it up >> >>> and replace it with something lightweight, or they'll say "screw >it" >> >>> and go back to the vendor supplied hacked up Linux solution. >> >> I think that if the "architecturally pretty solution" behaves >worse than >> >> some ugly hacks, then it may be not so pretty or the architecture >is >> >> just broken >> >> by design. >> >> >> >>> So I highly recommend you profile things - and profile things >with >> >>> lots of small transactions. If the CAM overhead is more than a >tiny, >> >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. >:-) >> >> I don't really know what to compare with. For MMC/SD cards it is >pretty >> >> obvious, but then these cards will be likely the bottleneck, not >the >> stack. >> >> And the only goal would be to not make the stack slower than it is >now. >> >> But, as ATA devices are much faster than MMC/SD, I don't think >this will >> >> be a problem. >> >> >> >> For SDIO things are different. But we don't have any drivers >(yet), >> except >> >> mv_sdiowl that I'm writing, to test on. So I have to bring the >SDIO >> >> stack on CAM, >> >> than bring mv_sdiowl to the state when it can actually transmit >the >> >> data, and then >> >> compare performance with the vendor-supplied Linux driver. >> >> We'll see then if there is a room for improvement... >> > That sounds like a plan. >> > >> > Just note that although storage looks like it's doing much more >> > throughput, the IO size also matters. As I said above, it's not >> > uncommon to have > 1000 receive frames a second on 802.11n; and >that >> > can peak much higher than that. That's not the kind of IO rate you >see >> > on SD cards. :-) >> > >> > >> > >> > -a >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >> > >> >> >> -- >> Regards, >> Ilya Bakulin >> >> >> > >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 >もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 >複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 >--- >CONFIDENTIALITY NOTE: The information in this email is confidential >and intended solely for the addressee. >Disclosure, copying, distribution or any other action of use of this >email by person other than intended recipient, is prohibited. >If you are not the intended recipient and have received this email in >error, please destroy the original message. -- Простите за краткость, создано в K-9 Mail. From owner-freebsd-hackers@freebsd.org Thu Feb 11 18:47:27 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04C16AA63D6; Thu, 11 Feb 2016 18:47:27 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 67BB7BC7; Thu, 11 Feb 2016 18:47:25 +0000 (UTC) (envelope-from ilya@bakulin.de) DKIM-Filter: OpenDKIM Filter v2.10.3 olymp.kibab.com 957324E674 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1455216445; bh=tRMeB9fG5vJN/yPGo7dqSSA4P1vEcY/rDAYmT+8+LtQ=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=pOW+ovNQ3aNiRD7U0ZG0lNWj3Pc6o6fFlMGUIPBynsJjBX/X9r3HnWZm1L5jV8nDU o7UeNUKeEUZ3D8UWYSXRPIECV6BbfNVQloI6YdEUiQaJZtR3Bv84ywb2C7L8eqwGcY wDhC7ELzEtkjTLG/1/DgzHqF7QAriJRaYhPKq0sc= In-Reply-To: References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> MIME-Version: 1.0 Subject: Re: MMC/SDIO stack under CAM From: Ilya Bakulin Date: Thu, 11 Feb 2016 19:47:09 +0100 To: "Lundberg, Johannes" CC: "freebsd-hackers@freebsd.org" , Adrian Chadd , Alexander Motin , "freebsd-arm@freebsd.org" Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 18:47:27 -0000 I'll use an excellent opportunity to post a small status update about my work :-) * SDHC controller on Wandboard now works with the new stack; * SDIO block read now works! * camcontrol userland app is extended to support "mmcsdcmd" command that allows to send MMC commands from userland apps directly to the card via pass(4) device -- now we can write WLAN driver in userland :-D On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" wrote: >Hi Ilya > >This is great! > >I've got a Tronsmart ARA X5 and just purchased a few UP > >boards >and it would be really nice if I could utilize the onboard eMMC. These >are >all Intel Cherrytrail platforms. > >Please let me know if there's anything (testing?) I can do to speed up >the >process. > > > >-- >Name: Johannes Lundberg >Position: Mirama project leader >Phone: +1-408-636-2161 >Skype: brilliantjohannes >Online: LinkedIn >Facebook > Reddit > Twitter > GitHub > >GitLab >Company: Mirama Brilliantservice US > Brilliantservice JP > > >On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin wrote: > >> So, more than one year has passed, and I'd like to resurrect this >work >> and move forward. >> >> I have uploaded a new diff and created a completely new revision to >> track the development: https://reviews.freebsd.org/D4761 >> >> What it is able to do now: >> >> * Read/write on SD/SDHC/MMC cards! >> * Detect SDIO cards and create devices that correspond to SDIO >functions >> >> This all works only on BeagleBone currently, because some changes >need >> to be done in each SDHCI-compliant driver to make it interact with >CAM. >> I have purchased a Wandboard Quad that has an integrated SDIO WiFi >chip, >> so I hope to tweak its SDHCI driver as well. >> >> I haven't profiled the stack because: >> * Now we have only SD/MMC cards that are slow anyway; >> * I don't know how to do it in FreeBSD :-) >> >> Please review this diff and tell what you think! >> >> On 01/03/14 18:05, Adrian Chadd wrote: >> > On 1 March 2014 08:46, Ilya Bakulin wrote: >> >> Hi Adrian, >> >> >> >> On 24.02.14, 16:59, Adrian Chadd wrote: >> >>> hi, >> >>> >> >>> Let me just reiterate some .. well, experience doing this stuff >at QCA. >> >>> >> >>> You really, absolutely don't want too much overhead in the >MMC/SDIO >> >>> path between whatever is issuing things and the network driver. >> >>> >> >>> There was significant performance work done at QCA on a local >MMC/SDIO >> >>> driver and bus to get extremely low latency and CPU utilisation >when >> >>> pushing around small transactions. The current CAM locking model >is >> >>> not geared towards getting to high transaction rates. >> >> So here you mean some work done on Linux MMC/SDIO stack by QCA >> >> which made it far better than current Linux MMC stack in terms of >> >> high SDIO I/O rates? >> > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at >small >> > transactions to sustain the wifi speeds customers required. >> > >> >>> You may think this is a very architecturally pretty solution and >it >> >>> indeed may be. But if it doesn't perform as well as the existing >local >> >>> hacks that vendors have done, no company deploying this hardware >is >> >>> going to want to use it. They'll end up realising there's this >massive >> >>> CAM storage layer in between and either have to sit down to rip >it up >> >>> and replace it with something lightweight, or they'll say "screw >it" >> >>> and go back to the vendor supplied hacked up Linux solution. >> >> I think that if the "architecturally pretty solution" behaves >worse than >> >> some ugly hacks, then it may be not so pretty or the architecture >is >> >> just broken >> >> by design. >> >> >> >>> So I highly recommend you profile things - and profile things >with >> >>> lots of small transactions. If the CAM overhead is more than a >tiny, >> >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. >:-) >> >> I don't really know what to compare with. For MMC/SD cards it is >pretty >> >> obvious, but then these cards will be likely the bottleneck, not >the >> stack. >> >> And the only goal would be to not make the stack slower than it is >now. >> >> But, as ATA devices are much faster than MMC/SD, I don't think >this will >> >> be a problem. >> >> >> >> For SDIO things are different. But we don't have any drivers >(yet), >> except >> >> mv_sdiowl that I'm writing, to test on. So I have to bring the >SDIO >> >> stack on CAM, >> >> than bring mv_sdiowl to the state when it can actually transmit >the >> >> data, and then >> >> compare performance with the vendor-supplied Linux driver. >> >> We'll see then if there is a room for improvement... >> > That sounds like a plan. >> > >> > Just note that although storage looks like it's doing much more >> > throughput, the IO size also matters. As I said above, it's not >> > uncommon to have > 1000 receive frames a second on 802.11n; and >that >> > can peak much higher than that. That's not the kind of IO rate you >see >> > on SD cards. :-) >> > >> > >> > >> > -a >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >> > >> >> >> -- >> Regards, >> Ilya Bakulin >> >> >> > >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 >もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 >複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 >--- >CONFIDENTIALITY NOTE: The information in this email is confidential >and intended solely for the addressee. >Disclosure, copying, distribution or any other action of use of this >email by person other than intended recipient, is prohibited. >If you are not the intended recipient and have received this email in >error, please destroy the original message. -- Простите за краткость, создано в K-9 Mail. From owner-freebsd-hackers@freebsd.org Thu Feb 11 18:54:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97764AA68A4; Thu, 11 Feb 2016 18:54:21 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (mx0.deglitch.com [IPv6:2a00:13c0:63:7194:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5B967119E; Thu, 11 Feb 2016 18:54:21 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [192.168.11.14] (unknown [98.248.95.7]) by mx0.deglitch.com (Postfix) with ESMTPSA id 0DF598FC0A; Thu, 11 Feb 2016 10:54:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: MMC/SDIO stack under CAM From: Stanislav Sedov In-Reply-To: Date: Thu, 11 Feb 2016 10:54:12 -0800 Cc: "Lundberg, Johannes" , Adrian Chadd , "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6942A46B-110B-4E1F-9DA1-F965009E8E92@FreeBSD.org> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> To: Ilya Bakulin X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 18:54:21 -0000 > On Feb 11, 2016, at 10:47 AM, Ilya Bakulin wrote: >=20 > I'll use an excellent opportunity to post a small status update about = my work :-) > * SDHC controller on Wandboard now works with the new stack; > * SDIO block read now works! > * camcontrol userland app is extended to support "mmcsdcmd" command = that allows to send MMC commands from userland apps directly to the card = via pass(4) device -- now we can write WLAN driver in userland :-D Great news, userspace drivers are the best!:) So what are the remaining pieces that prevent this work from hitting the = HEAD? -- Stanislav Sedov ST4096-RIPE From owner-freebsd-hackers@freebsd.org Thu Feb 11 18:55:27 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 739AEAA696B for ; Thu, 11 Feb 2016 18:55:27 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 26A971302 for ; Thu, 11 Feb 2016 18:55:27 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-qg0-x233.google.com with SMTP id y89so45181160qge.2 for ; Thu, 11 Feb 2016 10:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4R5xfqx5Argp9EYfrvegPansNCf5hMjmT0eLGR8/rxg=; b=iDIhbqFd8Ky6YDXnqFIsGiZGiNDUA6PlxoCr0FCAj2fk5xfjCR6O02FA+9vForAuDa bKLFJbpi7Uae1VjdZkVgqSWHJcIduDUPryDvmgSi2b1wPQGEI6P5KILswrFiTMqx2x0D qv0rDn2Z012do9tX2sVBnNbgBuwfJHuAjLwuJXBjPLzM0vSKlLEDNV5nbNUfJdFM9Mww dOXzQTBXhxNSptwIO+EvT0CMzYlpleEbpapqfz1iEvD5AfAm0eXe0pmY7H8OjGXLqokc +pvVodaHv/HTUwQTzf6NYVUfLyy3oi2awFfsUwMksmVnHM85dqLe9AcwXJYsfzN2UjnB KlEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4R5xfqx5Argp9EYfrvegPansNCf5hMjmT0eLGR8/rxg=; b=fczfzkUaul4+yngJYqVBb0H60u1fNRCQY/xT3d64RbkllkixJhiZ/EC594DgBi03Gx T27vzW3L5BgvUIafb5km+btXrTbX1wFERCZW90xLeAez/duLLCGGHOVI40CA5LBlU7uP +HZO3IhFSZgfTgZs6UBkHh9DPaNFDRfyP99vZ695fjpxnXqfC7WValC6yzwGosc1yPXM PTe7DZUyPxhN6X5NdTRMKaR+xkCBnsyWHS7cx2dWQXXaPrAS+fQBrKXUUiSecj5EM8Uk MlpCSz99SiPjxCCYekpsIiiLfXx8ov1mVsttBiZg8mfmcQrH+++eIGUtC9O3FqN9PW7H sm3A== X-Gm-Message-State: AG10YOTH8ME7ng0lvQZb23GqElmM+9J4g/VOivprW99QBPLoMWgyuxukoFpCdlMvGBS2NgFWuVjLe+s2BMmXL7M/2Go+XS9MefO4MJNREVAFeFSdXudwfJeV7KGlvGYOLzf4lQHEMKxLxfxrhwWS90Oy0Rc= X-Received: by 10.140.40.37 with SMTP id w34mr58162699qgw.85.1455216925862; Thu, 11 Feb 2016 10:55:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.45.71 with HTTP; Thu, 11 Feb 2016 10:55:11 -0800 (PST) In-Reply-To: References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> From: "Lundberg, Johannes" Date: Thu, 11 Feb 2016 10:55:11 -0800 Message-ID: Subject: Re: MMC/SDIO stack under CAM To: Ilya Bakulin Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Alexander Motin , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 18:55:27 -0000 Hi Ilya The controller is Intel, https://pci-ids.ucw.cz/read/PC/8086/0f14 It was added in Linux some time ago http://lxr.free-electrons.com/source/drivers/mmc/host/sdhci-acpi.c I'm not sure how much work is needed to get the controller working...? I'm kind of new to device driver development. -- Name: Johannes Lundberg Position: Mirama project leader Phone: +1-408-636-2161 Skype: brilliantjohannes Online: LinkedIn Facebook Reddit Twitter GitHub GitLab Company: Mirama Brilliantservice US Brilliantservice JP On Thu, Feb 11, 2016 at 10:42 AM, Ilya Bakulin wrote: > Hi Johannes, > > My work doesn't include writing drivers for SDHCI controllers. But if the > controller on your new boards is supported by FreeBSD, then you can reall= y > test the new stack! Especially if the controller driver for your board is > based on dev/sdhci, adapting it to work with the new stack is trivial. Fo= r > example, iMX6 SDHCI needed only a couple of lines: > https://github.com/kibab/freebsd/commit/df6d8d534740aa3633979da0a9d0ca00b= 60db0e9 > > Please let me know when you get the new boards and we will figure out wha= t > we need. > > On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" < > johannes@brilliantservice.co.jp> wrote: > >> Hi Ilya >> >> This is great! >> >> I've got a Tronsmart ARA X5 and just purchased a few UP >> >> boards and it would be really nice if I could utilize the onboard eMMC. >> These are all Intel Cherrytrail platforms. >> >> Please let me know if there's anything (testing?) I can do to speed up >> the process. >> >> >> >> -- >> Name: Johannes Lundberg >> Position: Mirama project leader >> Phone: +1-408-636-2161 >> Skype: brilliantjohannes >> Online: LinkedIn Facebook >> Reddit >> Twitter >> GitHub >> GitLab >> >> Company: Mirama Brilliantservice US >> Brilliantservice JP >> >> >> On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin wrote: >> >>> So, more than one year has passed, and I'd like to resurrect this work >>> and move forward. >>> >>> I have uploaded a new diff and created a completely new revision to >>> track the development: https://reviews.freebsd.org/D4761 >>> >>> What it is able to do now: >>> >>> * Read/write on SD/SDHC/MMC cards! >>> * Detect SDIO cards and create devices that correspond to SDIO function= s >>> >>> This all works only on BeagleBone currently, because some changes need >>> to be done in each SDHCI-compliant driver to make it interact with CAM. >>> I have purchased a Wandboard Quad that has an integrated SDIO WiFi chip= , >>> so I hope to tweak its SDHCI driver as well. >>> >>> I haven't profiled the stack because: >>> * Now we have only SD/MMC cards that are slow anyway; >>> * I don't know how to do it in FreeBSD :-) >>> >>> Please review this diff and tell what you think! >>> >>> On 01/03/14 18:05, Adrian Chadd wrote: >>> > On 1 March 2014 08:46, Ilya Bakulin wrote: >>> >> Hi Adrian, >>> >> >>> >> On 24.02.14, 16:59, Adrian Chadd wrote: >>> >>> hi, >>> >>> >>> >>> Let me just reiterate some .. well, experience doing this stuff at >>> QCA. >>> >>> >>> >>> You really, absolutely don't want too much overhead in the MMC/SDIO >>> >>> path between whatever is issuing things and the network driver. >>> >>> >>> >>> There was significant performance work done at QCA on a local >>> MMC/SDIO >>> >>> driver and bus to get extremely low latency and CPU utilisation whe= n >>> >>> pushing around small transactions. The current CAM locking model is >>> >>> not geared towards getting to high transaction rates. >>> >> So here you mean some work done on Linux MMC/SDIO stack by QCA >>> >> which made it far better than current Linux MMC stack in terms of >>> >> high SDIO I/O rates? >>> > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at smal= l >>> > transactions to sustain the wifi speeds customers required. >>> > >>> >>> You may think this is a very architecturally pretty solution and it >>> >>> indeed may be. But if it doesn't perform as well as the existing >>> local >>> >>> hacks that vendors have done, no company deploying this hardware is >>> >>> going to want to use it. They'll end up realising there's this >>> massive >>> >>> CAM storage layer in between and either have to sit down to rip it = up >>> >>> and replace it with something lightweight, or they'll say "screw it= " >>> >>> and go back to the vendor supplied hacked up Linux solution. >>> >> I think that if the "architecturally pretty solution" behaves worse >>> than >>> >> some ugly hacks, then it may be not so pretty or the architecture is >>> >> just broken >>> >> by design. >>> >> >>> >>> So I highly recommend you profile things - and profile things with >>> >>> lots of small transactions. If the CAM overhead is more than a tiny= , >>> >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. :-) >>> >> I don't really know what to compare with. For MMC/SD cards it is >>> pretty >>> >> obvious, but then these cards will be likely the bottleneck, not the >>> stack. >>> >> And the only goal would be to not make the stack slower than it is >>> now. >>> >> But, as ATA devices are much faster than MMC/SD, I don't think this >>> will >>> >> be a problem. >>> >> >>> >> For SDIO things are different. But we don't have any drivers (yet), >>> except >>> >> mv_sdiowl that I'm writing, to test on. So I have to bring the SDIO >>> >> stack on CAM, >>> >> than bring mv_sdiowl to the state when it can actually transmit the >>> >> data, and then >>> >> compare performance with the vendor-supplied Linux driver. >>> >> We'll see then if there is a room for improvement... >>> > That sounds like a plan. >>> > >>> > Just note that although storage looks like it's doing much more >>> > throughput, the IO size also matters. As I said above, it's not >>> > uncommon to have > 1000 receive frames a second on 802.11n; and that >>> > can peak much higher than that. That's not the kind of IO rate you se= e >>> > on SD cards. :-) >>> > >>> > >>> > >>> > -a >>> > _______________________________________________ >>> > freebsd-hackers@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> > To unsubscribe, send any mail to " >>> freebsd-hackers-unsubscribe@freebsd.org" >>> > >>> >>> >>> -- >>> Regards, >>> Ilya Bakulin >>> >>> >>> >> >> =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >> =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6= =EF=BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81= =97=E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98= =E5=8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3= =82=8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81= =BE=E3=81=99=E3=80=82 >> =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96= =E3=81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5= =A0=B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AE=E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5= =88=87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 >> =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE= =E4=BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8= =A8=98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81= =84=E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C= =E3=81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3= =81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >> --- >> CONFIDENTIALITY NOTE: The information in this email is confidential >> and intended solely for the addressee. >> Disclosure, copying, distribution or any other action of use of this >> email by person other than intended recipient, is prohibited. >> If you are not the intended recipient and have received this email in >> error, please destroy the original message. > > > -- > =D0=9F=D1=80=D0=BE=D1=81=D1=82=D0=B8=D1=82=D0=B5 =D0=B7=D0=B0 =D0=BA=D1= =80=D0=B0=D1=82=D0=BA=D0=BE=D1=81=D1=82=D1=8C, =D1=81=D0=BE=D0=B7=D0=B4=D0= =B0=D0=BD=D0=BE =D0=B2 K-9 Mail. > --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-hackers@freebsd.org Fri Feb 12 20:21:59 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D638BAA7D4E for ; Fri, 12 Feb 2016 20:21:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 A838115B1 for ; Fri, 12 Feb 2016 20:21:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ob0-x229.google.com with SMTP id is5so136358908obc.0 for ; Fri, 12 Feb 2016 12:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=HLuzFLVT/divY/UuDvPv6gvlro9UX8gOPiYpznR+mM8=; b=VeawCux+cSuO8A9+gy1fdUQ3LaKClQYoGrBjQKiobhGfj7J/y1ZQU0ybIvjlGBWtQx OUnlZZiFPknu0OfmGv67sN4IKSeg7HSr1KFktssz4GwheSYuEdqpn9xhnGlDHVmxj3aH EaWqA7j4kvKOBn78MBpJjumSUc9/8ywEgEy/JTPFT3vKfcjIfeP+1Gq5iNgRCxoVJgaS GPTBtUwSe5+DUKyXi/KH1qdX43X/RRuz2NtIxYg2FCLmHNkxNWzCWxr+m/DAnrChmn6k eQD3gzVtTxLXhcRkYQ2DWpPs23/jz2WKfOkqH75iUrgb/iQ0sxMktZ2tYJ6tPq7AHw0M wlKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=HLuzFLVT/divY/UuDvPv6gvlro9UX8gOPiYpznR+mM8=; b=RtPQmjmQQYnO7kl7Tk4evdcYGqrkhGGIcbVzjEY+amEp/MLkkU5N5w1L3AmwDwThvp d4OHJ3PLEZQ7c8AtWtG1OWoYsjySYFTLsPRcrCQbKwrCbh2yN988CSZBuR4Y1s1/VN8p Ff4Y6QCU30okTHKU/i2M/7lSOmklSTobhnhb/jQUj5vY3c2qIe3YRNZXnyDGtYcbTumh sFyyRCHIRjHY7CuKJvR+Qi7lPAIvKxDEU96najHyX5wvgqP19VKAvJtMBms19nYw6uM4 HDsqXI6liBTZwRqXBPZ1v+RcDGaWPjdbVvWNFxHSl0BS98GxLEEVcnuAZC9+VlYpHTiW 1cxw== X-Gm-Message-State: AG10YOSGWm7ZprHcmX6NHJlJgdm+OOhMPwb4F6Pn1o3S6cXyW06c0NMp1NcvTJq3eOpuQrpUkiGJjlvUmG4Nyw== MIME-Version: 1.0 X-Received: by 10.182.63.42 with SMTP id d10mr2870673obs.65.1455308518533; Fri, 12 Feb 2016 12:21:58 -0800 (PST) Sender: asomers@gmail.com Received: by 10.202.78.83 with HTTP; Fri, 12 Feb 2016 12:21:58 -0800 (PST) Date: Fri, 12 Feb 2016 13:21:58 -0700 X-Google-Sender-Auth: 4XP61skx7-pvxK0HdfM-3gBHIkg Message-ID: Subject: Page faults in getnewvnode with memguard(9) enabled From: Alan Somers To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 20:21:59 -0000 Prospecting for memory errors in ZFS, I tried running the ZFS test suite with memguard enabled. But as soon as I enable it, I hit the following panic within a few seconds. Line 1350 of vfs_subr.c simply accesses an object that was just allocated. I can't see anything wrong with the code, so I suspect a bug in memguard. Has anybody successfully used memguard on recent kernels? My memguard setting is "vm.memguard.frequency=100", so all memory allocations will be protected with a probability of 0.1%. If instead I leave vm.memguard.frequency=0 and set vm.memguard.desc=solaris, I don't hit this panic. I wonder if certain uma zones need to be off-limits to memguard's protection. #1 0xffffffff8038a6cb in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/home/alans/freebsd/head/sys/ddb/db_command.c:533 #2 0xffffffff8038a4be in db_command (cmd_table=0x0) at /usr/home/alans/freebsd/head/sys/ddb/db_command.c:440 #3 0xffffffff8038a254 in db_command_loop () at /usr/home/alans/freebsd/head/sys/ddb/db_command.c:493 #4 0xffffffff8038cd5b in db_trap (type=, code=0) at /usr/home/alans/freebsd/head/sys/ddb/db_main.c:251 #5 0xffffffff80ae34c3 in kdb_trap (type=12, code=0, tf=) at /usr/home/alans/freebsd/head/sys/kern/subr_kdb.c:654 #6 0xffffffff80f38731 in trap_fatal (frame=0xfffffe20b3d1c090, eva=) at /usr/home/alans/freebsd/head/sys/amd64/amd64/trap.c:836 #7 0xffffffff80f38964 in trap_pfault (frame=0xfffffe20b3d1c090, usermode=) at /usr/home/alans/freebsd/head/sys/amd64/amd64/trap.c:691 #8 0xffffffff80f380fe in trap (frame=0xfffffe20b3d1c090) at /usr/home/alans/freebsd/head/sys/amd64/amd64/trap.c:442 #9 0xffffffff80f1b697 in calltrap () at /usr/home/alans/freebsd/head/sys/amd64/amd64/exception.S:234 #10 0xffffffff80b59404 in getnewvnode (tag=0xffffffff821df2a0 "zfs", mp=0xfffff80044649cc0, vops=0xffffffff821f1600, vpp=0xfffffe20b3d1c320) at /usr/home/alans/freebsd/head/sys/kern/vfs_subr.c:1350 #11 0xffffffff8213f49a in zfs_znode_alloc (zfsvfs=0xfffff8004e187000, db=0xfffff8018fbb0ca8, blksz=0, obj_type=DMU_OT_SA, hdl=0xfffff801256f5770) at /usr/home/alans/freebsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:630 #12 0xffffffff8213f30f in zfs_mknode (dzp=, vap=0xfffffe20b3d1c9d0, tx=0xfffff8012595a700, cr=0xfffff80044582400, flag=, zpp=0xfffffe20b3d1c840, acl_ids=0xfffffe20b3d1c808) at /usr/home/alans/freebsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:989 #13 0xffffffff8217655a in zfs_freebsd_mkdir (ap=) at /usr/home/alans/freebsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2284 #14 0xffffffff8108f076 in VOP_MKDIR_APV (vop=, a=) at vnode_if.c:1607 #15 0xffffffff80b6a5b9 in kern_mkdirat (td=, fd=, path=0x8023176c0
, segflg=UIO_USERSPACE, mode=) at vnode_if.h:665 #16 0xffffffff80f39108 in amd64_syscall (td=0xfffff8012537d9a0, traced=0) at subr_syscall.c:135 #17 0xffffffff80f1b97b in Xfast_syscall () at /usr/home/alans/freebsd/head/sys/amd64/amd64/exception.S:394 #18 0x0000000801a61dba in ?? () Previous frame inner to this frame (corrupt stack?) -Alan From owner-freebsd-hackers@freebsd.org Sat Feb 13 03:58:10 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36AC5AA5AA3; Sat, 13 Feb 2016 03:58:10 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05AC81CF3; Sat, 13 Feb 2016 03:58:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-io0-x234.google.com with SMTP id l127so110741344iof.3; Fri, 12 Feb 2016 19:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to:cc; bh=Xp55/YuHn5rPNs5/9VbDhKFAh+fvTyFLgu2rKstmg2U=; b=Szwgu/DCHIdoILcZO8a85wOtTGgndY3J4YFxLY0elVoa0IuTvCJN3cAgL4sjw66SlM 8EycPnbHfSc7X7k1WIkBRPBwjKMRTB3/zOFL/4BlbW+IRC3x0gRZS3gzL7qztzUWT8v3 ZrNG7HNsRq+Hy+jRw6q8xHMDaYwrG4BwwSzItmC1rMt9yUFnMkWbLF7QGKo6KUMMqf0z nC65PieLV5jrZbop9NAmONQRuzUFD3FXyUzLxQ9Z53HDVlsg4FaWytDXFa135KZ2dEzY DkCRLNBT0QCYsUJsHQd6/rPrXSQN1OviuiUaH0m198Gpvd9hj3nEUrNejFBsL1Jv41dP v/sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version :content-transfer-encoding:message-id:date:subject:from:in-reply-to :references:to:cc; bh=Xp55/YuHn5rPNs5/9VbDhKFAh+fvTyFLgu2rKstmg2U=; b=aPfheEiNSCzHUmjg2niPlrhMaAUAvW2+s+gD1mv98qmPXg7YzSvb08c+8sFfEjtg1u 0XAYcImzn0RdMU74Tfn4nhHLpBt+ukMslBzTUw7RMD6U4znJKa0CP49+ZsirpXLj/+aa 7O1aDg50MplwSdUuVE9CIdUB/EzoeJftSCEwd30R7Bs5R/VSiw2n2j9phwB+YQ7yk/HO wx5W8KjUDGlI3ixVFbgKwsPD6T2zTzxK2WrLYgeXDpfheYVJLphdKWxB5IC6EJKlhXc0 ryw0/Q2seYinAVgXsVJFhyIwSgAThYwF5YN7rQ4B2zGapuZEfs3fsXKYeXDfPi5OWOs+ QMPA== X-Gm-Message-State: AG10YOQCBN9J/Zy78AN4Amf8gD/Kf+vI49P7umawswJUT5tHx9KO3vqz4AcqbRk7QMdUIA== X-Received: by 10.107.152.142 with SMTP id a136mr6721597ioe.84.1455335889108; Fri, 12 Feb 2016 19:58:09 -0800 (PST) Received: from [127.0.0.1] ([209.52.88.27]) by smtp.gmail.com with ESMTPSA id v68sm7511666ioi.23.2016.02.12.19.58.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 19:58:08 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160213035806.4403283.12124.2928@gmail.com> Date: Fri, 12 Feb 2016 19:58:06 -0800 Subject: Re: MMC/SDIO stack under CAM From: Russell Haley In-Reply-To: References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> To: Ilya Bakulin , "Lundberg, Johannes" Cc: Adrian Chadd , freebsd-hackers@freebsd.org, Alexander Motin , freebsd-arm@freebsd.org X-Mailman-Approved-At: Sat, 13 Feb 2016 12:33:44 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 03:58:10 -0000 Hi Ilya, so does that mean I can take a linux driver for an SDIO wifi card = and build it using a reference to your library and everything should "just = work"? Thanks, Russ Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Koodo=C2=A0network. =C2=A0 Original Message =C2=A0 From: Ilya Bakulin Sent: Thursday, February 11, 2016 10:43 AM To: Lundberg, Johannes Cc: Adrian Chadd; freebsd-hackers@freebsd.org; Alexander Motin; freebsd-arm= @freebsd.org Subject: Re: MMC/SDIO stack under CAM Hi Johannes, My work doesn't include writing drivers for SDHCI controllers. But if the c= ontroller on your new boards is supported by FreeBSD, then you can really t= est the new stack! Especially if the controller driver for your board is ba= sed on dev/sdhci, adapting it to work with the new stack is trivial. For ex= ample, iMX6 SDHCI needed only a couple of lines: https://github.com/kibab/f= reebsd/commit/df6d8d534740aa3633979da0a9d0ca00b60db0e9 Please let me know when you get the new boards and we will figure out what = we need. On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" wrote: >Hi Ilya > >This is great! > >I've got a Tronsmart ARA X5 and just purchased a few UP > >boards >and it would be really nice if I could utilize the onboard eMMC. These >are >all Intel Cherrytrail platforms. > >Please let me know if there's anything (testing?) I can do to speed up >the >process. > > > >-- >Name: Johannes Lundberg >Position: Mirama project leader >Phone: +1-408-636-2161 >Skype: brilliantjohannes >Online: LinkedIn >Facebook > Reddit > Twitter > GitHub > >GitLab >Company: Mirama Brilliantservice US > Brilliantservice JP > > >On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin wrote: > >> So, more than one year has passed, and I'd like to resurrect this >work >> and move forward. >> >> I have uploaded a new diff and created a completely new revision to >> track the development: https://reviews.freebsd.org/D4761 >> >> What it is able to do now: >> >> * Read/write on SD/SDHC/MMC cards! >> * Detect SDIO cards and create devices that correspond to SDIO >functions >> >> This all works only on BeagleBone currently, because some changes >need >> to be done in each SDHCI-compliant driver to make it interact with >CAM. >> I have purchased a Wandboard Quad that has an integrated SDIO WiFi >chip, >> so I hope to tweak its SDHCI driver as well. >> >> I haven't profiled the stack because: >> * Now we have only SD/MMC cards that are slow anyway; >> * I don't know how to do it in FreeBSD :-) >> >> Please review this diff and tell what you think! >> >> On 01/03/14 18:05, Adrian Chadd wrote: >> > On 1 March 2014 08:46, Ilya Bakulin wrote: >> >> Hi Adrian, >> >> >> >> On 24.02.14, 16:59, Adrian Chadd wrote: >> >>> hi, >> >>> >> >>> Let me just reiterate some .. well, experience doing this stuff >at QCA. >> >>> >> >>> You really, absolutely don't want too much overhead in the >MMC/SDIO >> >>> path between whatever is issuing things and the network driver. >> >>> >> >>> There was significant performance work done at QCA on a local >MMC/SDIO >> >>> driver and bus to get extremely low latency and CPU utilisation >when >> >>> pushing around small transactions. The current CAM locking model >is >> >>> not geared towards getting to high transaction rates. >> >> So here you mean some work done on Linux MMC/SDIO stack by QCA >> >> which made it far better than current Linux MMC stack in terms of >> >> high SDIO I/O rates? >> > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at >small >> > transactions to sustain the wifi speeds customers required. >> > >> >>> You may think this is a very architecturally pretty solution and >it >> >>> indeed may be. But if it doesn't perform as well as the existing >local >> >>> hacks that vendors have done, no company deploying this hardware >is >> >>> going to want to use it. They'll end up realising there's this >massive >> >>> CAM storage layer in between and either have to sit down to rip >it up >> >>> and replace it with something lightweight, or they'll say "screw >it" >> >>> and go back to the vendor supplied hacked up Linux solution. >> >> I think that if the "architecturally pretty solution" behaves >worse than >> >> some ugly hacks, then it may be not so pretty or the architecture >is >> >> just broken >> >> by design. >> >> >> >>> So I highly recommend you profile things - and profile things >with >> >>> lots of small transactions. If the CAM overhead is more than a >tiny, >> >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. >:-) >> >> I don't really know what to compare with. For MMC/SD cards it is >pretty >> >> obvious, but then these cards will be likely the bottleneck, not >the >> stack. >> >> And the only goal would be to not make the stack slower than it is >now. >> >> But, as ATA devices are much faster than MMC/SD, I don't think >this will >> >> be a problem. >> >> >> >> For SDIO things are different. But we don't have any drivers >(yet), >> except >> >> mv_sdiowl that I'm writing, to test on. So I have to bring the >SDIO >> >> stack on CAM, >> >> than bring mv_sdiowl to the state when it can actually transmit >the >> >> data, and then >> >> compare performance with the vendor-supplied Linux driver. >> >> We'll see then if there is a room for improvement... >> > That sounds like a plan. >> > >> > Just note that although storage looks like it's doing much more >> > throughput, the IO size also matters. As I said above, it's not >> > uncommon to have > 1000 receive frames a second on 802.11n; and >that >> > can peak much higher than that. That's not the kind of IO rate you >see >> > on SD cards. :-) >> > >> > >> > >> > -a >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >> > >> >> >> -- >> Regards, >> Ilya Bakulin >> >> >> > >--=20 >=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6= =EF=BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81= =97=E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98= =E5=8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3= =82=8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81= =BE=E3=81=99=E3=80=82 >=E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96= =E3=81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5= =A0=B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AE=E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5= =88=87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 >=E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE= =E4=BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8= =A8=98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81= =84=E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C= =E3=81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3= =81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >--- >CONFIDENTIALITY NOTE: The information in this email is confidential >and intended solely for the addressee. >Disclosure, copying, distribution or any other action of use of this >email by person other than intended recipient, is prohibited. >If you are not the intended recipient and have received this email in >error, please destroy the original message. --=20 =D0=9F=D1=80=D0=BE=D1=81=D1=82=D0=B8=D1=82=D0=B5 =D0=B7=D0=B0 =D0=BA=D1=80= =D0=B0=D1=82=D0=BA=D0=BE=D1=81=D1=82=D1=8C, =D1=81=D0=BE=D0=B7=D0=B4=D0=B0= =D0=BD=D0=BE =D0=B2 K-9 Mail. _______________________________________________ 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-hackers@freebsd.org Sat Feb 13 06:48:54 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 331EFAA7103; Sat, 13 Feb 2016 06:48:54 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD955153B; Sat, 13 Feb 2016 06:48:53 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x22b.google.com with SMTP id e6so75786768vkh.2; Fri, 12 Feb 2016 22:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=m3AzWaJZdo4EeQPmjIX7g0XTjqjARbpfhMZOkTZLWWI=; b=HV0IWoy6lWkcB1VcSEy+3KX/Vx5Q5hNudo+L+3gHhFeEA0d7tMrrFe1j/TZ7JI0Nf2 p/rbD7uvs0ACZh+I2ZYZ8Ip79pvILAgg5Sglga4cqmL2hqcgumdK1PedC3JIeTj+fVGr o6evyaRQlo3USZKEKV3CH4getv3VrFBhivA8OImUu8HLvy7yyQ5+pEuJkExZhL4cp8SH hnzZ+gnFq1t2/59ZO+gUcNfVAbKIxLb8ysfOBTv8xEfIdEtd/oPp4Ub5oQzfjH+tkOXF zRq9HbyHYuqdevL5gH1SLsoabA0EpNKUewStqsGLEThGlZoM2UKyz8wLNeJ49CwQddVI /LAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m3AzWaJZdo4EeQPmjIX7g0XTjqjARbpfhMZOkTZLWWI=; b=h+Evb/AceOELJxDMOI/o3Qi03D2Y35EvSVK9px2jRMz6EDZ3JedCJQqON/cpgpGir0 ilKmv79ygrBqFc88c4EB69u3fus8xXO/Y++wnIfg+90xUbc5/rl8uqxlM4X2chURww/J n1UZkitR9yuIoRdJXce3LULtokWcTXk3oLkbO9AmJXF1d5CbTrPlQnL3teSLXxJhfWt6 Oc3Yhyq1g5R8O1NCgnNnxoqZMho/2ZndOggcDPcMVy59w4Sg7G7poTIAYJ+WEGcrT2a6 d9OxyhSSfFfwJ/ygicVp69KEN9Y41vyj81EAM0XTMpQ6Q8Grv3rHOKfEPPcfUexipEsI JAKQ== X-Gm-Message-State: AG10YOTrL2blwKkWw7OVEiJUkc8IvZoZc1oqcY5xpvrqx56smPgYQC+YnEuhvDign786xQ87usIO6NKMuhnwzA== MIME-Version: 1.0 X-Received: by 10.31.8.72 with SMTP id 69mr4669253vki.145.1455346132868; Fri, 12 Feb 2016 22:48:52 -0800 (PST) Received: by 10.31.54.13 with HTTP; Fri, 12 Feb 2016 22:48:52 -0800 (PST) In-Reply-To: References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> <20160213035806.4403283.12124.2928@gmail.com> Date: Fri, 12 Feb 2016 22:48:52 -0800 Message-ID: Subject: Re: MMC/SDIO stack under CAM From: Russell Haley To: Adrian Chadd Cc: Ilya Bakulin , "Lundberg, Johannes" , "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 13 Feb 2016 12:35:25 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 06:48:54 -0000 On Fri, Feb 12, 2016 at 8:16 PM, Adrian Chadd wrot= e: > On 12 February 2016 at 19:58, Russell Haley wrote: >> Hi Ilya, so does that mean I can take a linux driver for an SDIO wifi ca= rd and build it using a reference to your library and everything should "ju= st work"? > > nope. there's a lot more to it than that. But it's a good start - > getting the driver up and doing IO to the card is a big step. > > > > -a > Okay, thanks. But if I include his CAM driver and then use the patch below for IMX6 on my Hummingboard, I would be able to test the driver? Will a simple kldstat be enough to verify I am using his driver or is there something more direct in dtrace? Thanks, Russ >> Thanks, >> Russ >> >> Sent from my BlackBerry 10 smartphone on the Koodo network. >> Original Message >> From: Ilya Bakulin >> Sent: Thursday, February 11, 2016 10:43 AM >> To: Lundberg, Johannes >> Cc: Adrian Chadd; freebsd-hackers@freebsd.org; Alexander Motin; freebsd-= arm@freebsd.org >> Subject: Re: MMC/SDIO stack under CAM >> >> Hi Johannes, >> >> My work doesn't include writing drivers for SDHCI controllers. But if th= e controller on your new boards is supported by FreeBSD, then you can reall= y test the new stack! Especially if the controller driver for your board is= based on dev/sdhci, adapting it to work with the new stack is trivial. For= example, iMX6 SDHCI needed only a couple of lines: https://github.com/kiba= b/freebsd/commit/df6d8d534740aa3633979da0a9d0ca00b60db0e9 >> >> Please let me know when you get the new boards and we will figure out wh= at we need. >> >> On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" wrote: >>>Hi Ilya >>> >>>This is great! >>> >>>I've got a Tronsmart ARA X5 and just purchased a few UP >>> >>>boards >>>and it would be really nice if I could utilize the onboard eMMC. These >>>are >>>all Intel Cherrytrail platforms. >>> >>>Please let me know if there's anything (testing?) I can do to speed up >>>the >>>process. >>> >>> >>> >>>-- >>>Name: Johannes Lundberg >>>Position: Mirama project leader >>>Phone: +1-408-636-2161 >>>Skype: brilliantjohannes >>>Online: LinkedIn >>>Facebook >>> Reddit >>> Twitter >>> GitHub >>> >>>GitLab >>>Company: Mirama Brilliantservice US >>> Brilliantservice JP >>> >>> >>>On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin wrote: >>> >>>> So, more than one year has passed, and I'd like to resurrect this >>>work >>>> and move forward. >>>> >>>> I have uploaded a new diff and created a completely new revision to >>>> track the development: https://reviews.freebsd.org/D4761 >>>> >>>> What it is able to do now: >>>> >>>> * Read/write on SD/SDHC/MMC cards! >>>> * Detect SDIO cards and create devices that correspond to SDIO >>>functions >>>> >>>> This all works only on BeagleBone currently, because some changes >>>need >>>> to be done in each SDHCI-compliant driver to make it interact with >>>CAM. >>>> I have purchased a Wandboard Quad that has an integrated SDIO WiFi >>>chip, >>>> so I hope to tweak its SDHCI driver as well. >>>> >>>> I haven't profiled the stack because: >>>> * Now we have only SD/MMC cards that are slow anyway; >>>> * I don't know how to do it in FreeBSD :-) >>>> >>>> Please review this diff and tell what you think! >>>> >>>> On 01/03/14 18:05, Adrian Chadd wrote: >>>> > On 1 March 2014 08:46, Ilya Bakulin wrote: >>>> >> Hi Adrian, >>>> >> >>>> >> On 24.02.14, 16:59, Adrian Chadd wrote: >>>> >>> hi, >>>> >>> >>>> >>> Let me just reiterate some .. well, experience doing this stuff >>>at QCA. >>>> >>> >>>> >>> You really, absolutely don't want too much overhead in the >>>MMC/SDIO >>>> >>> path between whatever is issuing things and the network driver. >>>> >>> >>>> >>> There was significant performance work done at QCA on a local >>>MMC/SDIO >>>> >>> driver and bus to get extremely low latency and CPU utilisation >>>when >>>> >>> pushing around small transactions. The current CAM locking model >>>is >>>> >>> not geared towards getting to high transaction rates. >>>> >> So here you mean some work done on Linux MMC/SDIO stack by QCA >>>> >> which made it far better than current Linux MMC stack in terms of >>>> >> high SDIO I/O rates? >>>> > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at >>>small >>>> > transactions to sustain the wifi speeds customers required. >>>> > >>>> >>> You may think this is a very architecturally pretty solution and >>>it >>>> >>> indeed may be. But if it doesn't perform as well as the existing >>>local >>>> >>> hacks that vendors have done, no company deploying this hardware >>>is >>>> >>> going to want to use it. They'll end up realising there's this >>>massive >>>> >>> CAM storage layer in between and either have to sit down to rip >>>it up >>>> >>> and replace it with something lightweight, or they'll say "screw >>>it" >>>> >>> and go back to the vendor supplied hacked up Linux solution. >>>> >> I think that if the "architecturally pretty solution" behaves >>>worse than >>>> >> some ugly hacks, then it may be not so pretty or the architecture >>>is >>>> >> just broken >>>> >> by design. >>>> >> >>>> >>> So I highly recommend you profile things - and profile things >>>with >>>> >>> lots of small transactions. If the CAM overhead is more than a >>>tiny, >>>> >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. >>>:-) >>>> >> I don't really know what to compare with. For MMC/SD cards it is >>>pretty >>>> >> obvious, but then these cards will be likely the bottleneck, not >>>the >>>> stack. >>>> >> And the only goal would be to not make the stack slower than it is >>>now. >>>> >> But, as ATA devices are much faster than MMC/SD, I don't think >>>this will >>>> >> be a problem. >>>> >> >>>> >> For SDIO things are different. But we don't have any drivers >>>(yet), >>>> except >>>> >> mv_sdiowl that I'm writing, to test on. So I have to bring the >>>SDIO >>>> >> stack on CAM, >>>> >> than bring mv_sdiowl to the state when it can actually transmit >>>the >>>> >> data, and then >>>> >> compare performance with the vendor-supplied Linux driver. >>>> >> We'll see then if there is a room for improvement... >>>> > That sounds like a plan. >>>> > >>>> > Just note that although storage looks like it's doing much more >>>> > throughput, the IO size also matters. As I said above, it's not >>>> > uncommon to have > 1000 receive frames a second on 802.11n; and >>>that >>>> > can peak much higher than that. That's not the kind of IO rate you >>>see >>>> > on SD cards. :-) >>>> > >>>> > >>>> > >>>> > -a >>>> > _______________________________________________ >>>> > freebsd-hackers@freebsd.org mailing list >>>> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> > To unsubscribe, send any mail to " >>>> freebsd-hackers-unsubscribe@freebsd.org" >>>> > >>>> >>>> >>>> -- >>>> Regards, >>>> Ilya Bakulin >>>> >>>> >>>> >>> >>>-- >>>=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >>>=E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6= =EF=BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81= =97=E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98= =E5=8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3= =82=8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81= =BE=E3=81=99=E3=80=82 >>>=E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96= =E3=81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5= =A0=B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AE=E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5= =88=87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 >>>=E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE= =E4=BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8= =A8=98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81= =84=E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C= =E3=81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3= =81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >>>--- >>>CONFIDENTIALITY NOTE: The information in this email is confidential >>>and intended solely for the addressee. >>>Disclosure, copying, distribution or any other action of use of this >>>email by person other than intended recipient, is prohibited. >>>If you are not the intended recipient and have received this email in >>>error, please destroy the original message. >> >> -- >> =D0=9F=D1=80=D0=BE=D1=81=D1=82=D0=B8=D1=82=D0=B5 =D0=B7=D0=B0 =D0=BA=D1= =80=D0=B0=D1=82=D0=BA=D0=BE=D1=81=D1=82=D1=8C, =D1=81=D0=BE=D0=B7=D0=B4=D0= =B0=D0=BD=D0=BE =D0=B2 K-9 Mail. >> _______________________________________________ >> 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-hackers@freebsd.org Sat Feb 13 16:40:15 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11A7EAA1FCD for ; Sat, 13 Feb 2016 16:40:15 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1C711834 for ; Sat, 13 Feb 2016 16:40:14 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id A85C21534E5 for ; Sat, 13 Feb 2016 17:40:08 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka8ptdepiK9k; Sat, 13 Feb 2016 17:39:47 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 868FC1534E6 for ; Sat, 13 Feb 2016 17:30:05 +0100 (CET) To: freebsd-hackers@freebsd.org From: Willem Jan Withagen Subject: Debugging C++ code with atexit functions not called.. X-Enigmail-Draft-Status: N1110 Message-ID: <56BF5A0C.6060503@digiware.nl> Date: Sat, 13 Feb 2016 17:30:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 16:40:15 -0000 Hi, I've rn into a snag with porting some of the Ceph code.... PID file cleanup is done tru a atexit(pidfile_remove) setup. Ive augmented the code and I see that the last thing the Linux version does is actually execute the pidfile_remove code. Whereas on FreeBSD this does not happen, the function does not seem to be called at all.. The most obvious reason would be a crash of the program, but I don't get a core file... But to terminate the program I have to send it a 'kill TERM'. Doing so under gdb gdb prints: [New Thread 806c91800 (LWP 101527 sginal_handler)] [New Thread 806c91400 (LWP 101519 ms_accepter)] [New Thread 806c91000 (LWP 101512 ms_local)] [New Thread 804dffc00 (LWP 101509 ms_dispatch)] [New Thread 804dff800 (LWP 101489 safe_timer)] [New Thread 804dff400 (LWP 100256 ms_reaper)] [New Thread 804dff000 (LWP 100223 fn_monstore)] [New Thread 804c15c00 (LWP 100206 admin_socket)] [New Thread 804c15800 (LWP 100193 service)] [New Thread 804c15400 (LWP 100167 log)] Program received signal SIGTERM, Terminated. [Switching to Thread 804c15000 (LWP 101222)] 0x00000008025ea1fc in _umtx_op_err () from /lib/libthr.so.3 (gdb) Are these threads being fired up by the program upon receiving the signal? Continuing gives me some of the programs output, and it prints that it has received a signal. The break on the pidfile_remove is not triggered. Suggesting that it does not call the atexit-functions... Suggestions on how to debug this further.... --WjW